Le rôle de validateur et les processus de validation et de bêta

Hello tout le monde,

En lien avec le débat en cours sur les perspectives d’évolutions du système éditorial et le prochain recrutement de validateurs au sein du staff, je reviens vers vous avec une idée à court et moyen terme pour insuffler quelque chose de nouveau dans notre processus de validation.

Comme vous ne l’ignorez sûrement pas, il a toujours été difficile d’avoir un large panel (il est large, mais pas assez) de compétences au sein du staff pour traiter les tutos en attente en validation ou bêta. Et le fait que le staff a toujours été — c’était une volonté à la base — d’une taille réduite (plus facile à gérer) implique que notre charge de travail augmente dès que l’un d’entre nous manque de disponibilité. Ce qui est logique, après tout, vu que nous sommes tous bénévoles ici.

Je ne vais pas revenir sur les idées qui se dégagent sur le sujet linké plus haut. En revanche, je souhaiterais qu’on table sur ce qu’il est possible de faire maintenant et à court voire moyen terme pour essayer d’améliorer les choses. Bref, il s’agit de dégager des solutions qui peuvent être implémentées rapidement, ou le plus rapidement possible. L’idée ici n’est pas d’avoir une solution parfaite mais de tenter une autre approche, en espérant que cela fonctionnera.

1. Ouvrir le rôle de validateur et redéfinir en partie le rôle du staff (maintenant/court terme)

Si l’on reprend la situation actuelle, que se passe-t-il lorsqu’un contenu arrive en validation (limitons-nous, pour l’exemple, à la validation) et que personne au sein du staff n’a les compétences ou le temps pour s’en occuper ?

Et bien, la politique est de faire appel aux contributions de membres. Mais le problème est que, si les outils de validation sont corrects mais peu adaptés pour le staff, les membres qui se proposent pour faire ce travail, eux, n’ont juste aucun accès aux outils déjà disponibles. Ils sont dans une situation encore plus précaire que le staff !

Et pour l’instant, pour pouvoir accéder à ces outils, il faut avoir la casquette "Staff". Je propose, dès lors, de casser ce système par la création d’une casquette "Validateur", joignable sur demande (et de même pour le départ), permettant aux membres désireux de valider tel ou tel contenus d’avoir au moins accès à nos outils (historique, marquer tel ou tel sujet à ne pas publier, etc.) et à un forum Validation pour échanger avec les autres validateurs, discuter avec le staff, etc.

On a déjà, dans le guide du contributeur, des éléments portant sur la validation et je pense qu’il est aussi nécessaire d’ouvrir une discussion au sein du staff pour préparer des guides dans cette optique de facilité l’accès à la validation

Faire évoluer le rôle du staff

Bien entendu, le staff préservera ses droits actuels et pourra continuer à valider du contenu, mais il pourra aussi avoir un rôle de référent, de coordination — rôle qui était tenu sur le SdZ par @Thunderseb — pour les validateurs afin de les assister et de dynamiser un peu tout ça.

2. Améliorer la visibilité et la prise en charge du contenu dès la bêta par la création d’un système de notification (court-moyen terme)

Le système de bêta actuel ne fonctionne pas car le contenu est principalement invisible (aux membres, mais aussi au staff qui n’a pas (forcément) le temps de prendre en charge les contenus dès la bêta ou ne voit pas tous les sujets créés malgré toute notre bonne volonté, c’est par exemple mon cas).

Ce que je propose ici est de créer un système permettant à tout membre — lorsqu’il désire participer à la validation en obtenant la casquette associée — d’indiquer les thématiques et sous-thématiques qui font partie de ses centres d’intérêts (droit, développement web, PHP, etc.). Couplé à un système de notification des nouveaux contenus en bêta relatifs à ces centres d’intérêts, cela permettra à un ou plusieurs validateur de réserver (dès la bêta) tel ou tel contenu et d’assister l’auteur dès le départ.

Entretemps, je propose — lors du prochain recrutement pour le staff — de recruter dans le même temps une liste de membres volontaires avec pour tâche principale de se concentrer sur la bêta pour y aider les auteurs de contenus et superviser (fond et/ou forme) ces rédactions. On ne l’a jamais fait, parce que nous avons toujours souhaité garder une équipe de taille raisonnable, ce qui excluait d’office un recrutement plus important. Je pense qu’il faut élargir notre capacité et être beaucoup plus proactif.

FAIT

3. Développer un meilleur outil de validation permettant, notamment, de commenter directement les contenus (moyen-long terme)

Sur ce point, je ne vais pas m’étendre. Plusieurs sujets ont abordés ce point ces dernières années. Mais le développement de ces outils doit devenir, AMHA, une priorité. Cela facilitera le travail des validateurs et permettra dès lors d’améliorer la qualité de l’interaction validateur - auteur.

On avait parlé aussi de la possibilité de contacter la validation. J’avais proposé, avec une casquette validation du coup, la possibilité d’envoyer un MP à une casquette, qui du coup inclurait automatiquement tous les membres ayant cette casquette.

Autre proposition aussi (aucune idée de si elle est bien) : que les validateurs n’envoient pas tous leurs retours à la fin de leur premier cycle, mais peut-être les envoient au fur et à mesure, par petites vagues, pour tenir l’auteur au courant (et éventuellement lui permettre de travailler déjà dessus).

Autre proposition aussi (aucune idée de si elle est bien) : que les validateurs n’envoient pas tous leurs retours à la fin de leur premier cycle, mais peut-être les envoient au fur et à mesure, par petites vagues, pour tenir l’auteur au courant (et éventuellement lui permettre de travailler déjà dessus).

Ça peut être compliqué, compte tenu de la nature du contenu.

Sur la proposition du premier message, juste un gros oui.

Autre proposition aussi (aucune idée de si elle est bien) : que les validateurs n’envoient pas tous leurs retours à la fin de leur premier cycle, mais peut-être les envoient au fur et à mesure, par petites vagues, pour tenir l’auteur au courant (et éventuellement lui permettre de travailler déjà dessus).

Ça dépend aussi de la façon de travailler du validateur. Pour les contenus de longueur moyenne, je faisais typiquement ça en deux vagues, chacune résultant d’une session de relecture. Envoyer au fur et à mesure n’aurait pas de sens, dans ce cas-là.

Et pour l’instant, pour pouvoir accéder à ces outils, il faut avoir la casquette "Staff". Je propose, dès lors, de casser ce système par la création d’une casquette "Validateur", joignable sur demande (et de même pour le départ), permettant aux membres désireux de valider tel ou tel contenus d’avoir au moins accès à nos outils (historique, marquer tel ou tel sujet à ne pas publier, etc.) et à un forum Validation pour échanger avec les autres validateurs, discuter avec le staff, etc.

J’irais même plus loin : décorréler totalement la validation d’un contenu à un rôle. Actuellement, un validateur peut réserver un contenu pour s’en charger. L’idée serait de pouvoir ajouter n’importe qui (ou n’importe quel ensemble de personnes) comme validateur⋅trice sur un contenu (et que les personnes dans le groupe staff puissent s’ajouter soi-même, ou n’importe qui d’autre).

Être désigné⋅e validateur⋅trice sur un contenu donnerait accès à tous les outils de validation, et à une nouvelle option « donner son feu vert », qui indiquerait aux personnes dans le staff que c’est OK. Le staff garderait le contrôle de la publication elle-même.

Ça éviterait le fait d’avoir à être ajouté à un groupe (il faut passer par un super admin, c’est pas très fluide), et ça normaliserait le fait d’avoir des validos externes — après tout, c’est statistiquement normal de ne pas avoir la bonne compétence dans l’équipe).

Concernant la discussion, on pourrait ajouter les validateurs⋅trices du contenu (pas ceux du groupe, juste ceux du contenu) et les auteurs⋅trices à un MP, ou même mieux : avoir un nouveau fil intégré à l’interface de rédaction (pas un MP) avec dedans, les validateurs⋅trices du contenu, les auteurs⋅trices, et tous les membres du groupe “supervision de la validation” (ou autre enfin vous avez compris l’idée).

Le système de MP n’étant pas super adapté à un MP avec des milliers de participant⋅e⋅s, ça permettrait d’avoir un fil intégré au contenu directement (plus besoin de jongler) et avec moins de problématiques d’accès (rien à synchroniser, c’est juste lié au contenu et voilà).

D’un point de vue clarté, peut-être qu’on pourrait trouver un meilleur mot que “validateur”, d’ailleurs.

Ça éviterait le fait d’avoir à être ajouté à un groupe (il faut passer par un super admin, c’est pas très fluide), et ça normaliserait le fait d’avoir des validos externes — après tout, c’est statistiquement normal de ne pas avoir la bonne compétence dans l’équipe).

Yep. Mais gardons en tête qu’il s’agit ici de modifs à court terme.

Oui effectivement. Ce que je propose serait plutôt du moyen terme .

Ça ressemble au fonctionnement d’une revue scientifique. Un éditeur contacterait un/des validateurs parmi une liste de gens. Ces validateurs feraient le travail de validation et l’éditeur validerait à la fin la publication sur la base de ce travail. L’idée est bonne mais demande d’avoir une liste de validateurs disponibles et compétents régulièrement mise à jour

Ça peut aussi marcher en demandant à la cantonade (p.ex. sur Discord ou même sur des réseaux sociaux), ça a été fait plusieurs fois et ça marche pas si mal

Mais sinon, en effet, et à titre personnel ça me semble plus logique d’embrasser l’idée que la majorité des validos sont externes.

Tant qu’on ne tombe pas dans certains travers des journaux scientifiques tout va bien

D’où le fait d’exploiter les casquettes.

J’ai quelques doutes par rapport aux propositions sur la visibilité des bêtas parce que je ne sais pas si ça aurait un réel impact : est-ce que ça ne ressemblerait pas juste aux abonnement sur les tags qu’on a déjà ?

Mais +1 pour au moins expérimenter quelque chose, et aller plus loin si la visibilité n’est toujours pas là (par exemple un encart réservé aux dernières mises à jour en bêta comme je le proposais sur l’autre sujet, et une ouverture à l’extérieur).

Le staff a la liste des contenus en validation sur une page spécifique. Il n’y a pas moyen d’avoir une page similaire pour tous les contenus en béta ? Avec la possibilité, dès la béta pour les validateurs / staffs de s’ajouter ? Et cette liste pourrait être public accessible à tous.

Sur ce point, je ne vais pas m’étendre. Plusieurs sujets ont abordés ce point ces dernières années. Mais le développement de ces outils doit devenir, AMHA, une priorité. Cela facilitera le travail des validateurs et permettra dès lors d’améliorer la qualité de l’interaction validateur - auteur.

J’y ai réfléchi hier soir pour le fun de la chose. En fait, c’est vachement complexe : l’exemple que j’ai en tête, c’est celui de Github qui permet de commenter des lignes d’un commit. Sauf qu’on ne travaille pas trop en terme de commit (en interne, c’est ce qui se passe, mais si on ne va pas voir la page correspondante, c’est caché), et quand bien même j’ai pas l’impression que ce soit pratique (puisqu’ici, on s’intéresse plus au texte dans sa globalité qu’à des changements ponctuels, comme c’est le cas pour du code, et le rendu [par exemple du LaTeX] est important pour aider à le comprendre → je vois mal un validateur lire directement le markdown).

L’idée qui s’en rapproche le plus, c’est, d’un point de vue technique, de pouvoir attacher des remarques/commentaires à des bouts de texte. Sur le papier, ça parait évident, mais ça demande au moins de répondre à deux questions:

• Comment assurer la discussion autour d’une remarque ? (genre "je ne suis pas d’accord avec ta remarque parce que …" ou "moi je l’aurait plutôt vu comme ça")
• À quoi est ce qu’on rattache cette "remarque" ? → Si je pose la question, c’est pour savoir ce qui se passe lorsque le morceau de texte problématique est modifié : est ce que la remarque disparaît ? Sinon, est ce qu’il y a moyen de la marquer comme "résolue" et de la masquer ? (parce que sinon ça va être un peu lourd )

• Comment assurer la discussion autour d’une remarque ? (genre "je ne suis pas d’accord avec ta remarque parce que …" ou "moi je l’aurais plutôt vu comme ça")
• À quoi est ce qu’on rattache cette "remarque" ? → Si je pose la question, c’est pour savoir ce qui se passe lorsque le morceau de texte problématique est modifié : est ce que la remarque disparaît ? Sinon, est ce qu’il y a moyen de la marquer comme "résolue" et de la masquer ? (parce que sinon ça va être un peu lourd )

La plupart des remarques sont des propositions de corrections ou des remarques libres qui entraînent peu de discussions. Autrement dit, je pense qu’avoir trois états « non traité », « traité » et « en discussion » pour les remarques remplit le plus gros du besoin. Un truc du genre, cliquer sur la remarque la fait basculer d’état ? La discussion peut se faire dans le MP de validation. Ce qui est inutilement lourd, ce n’est pas de discuter dans le MP, c’est de régler tous les petits soucis, de pointer au bon endroit, et de vérifier si ça a été pris en compte ou non, etc.

Si le validateur n’est pas content de la réponse à son commentaire, il peut basculer de « traité » vers « en discussion ». Et pour éviter d’avoir plein de trucs corrigés qui traînent, un bouton « supprimer toutes les remarques traitées ». Ça part du principe qu’une remarque marquée comme traitée par l’auteur et non explicitement basculée par le validateur est effectivement traitée, mais ça me semble raisonnable, comme comportement. Faut juste ne pas tout supprimer avant d’avoir tout relu.

Un peu comme les correcteurs de grammaires, qui surlignent, t’expliquent la règle, et proposent (souvent) une correction. Sauf qu’on garde le fait qu’il y avait une faute ici jusqu’à ce que le validateur demande qu’on efface l’historique.

Je pense que ce bout de discussion aurait plus sa place dans un fil dédié à un système de commentaires.

Mais il n’est pas techniquement complexe d’attacher un fil de commentaires à une note. Et d’un point de vue utilisateur, c’est encore le plus simple, couplé à la possibilité de fermer une note.

Peut-on avoir un avis technique sur la faisabilité des deux premières propositions à court terme ? Est-ce déjà réalisable maintenant côté backend ?

Mise à jour du premier post.

Petit up par ici pour avoir vos retours quant à l’activité de la bêta.

Le staff semble plus actif sur le forum bêta qu’auparavant et c’est une bonne chose. Je reste cependant convaincu que les points relevés ici (et sur le second sujet donné en lien dans l’OP) restent importants.

Je suis d’accord avec toi, il semble y avoir un léger sursaut avec un peu plus de participation sur les sujets de bêta (notamment pour orienter les nouveaux contenus).
Mais ça me semble quand même très léger, la visibilité n’est pas meilleure et c’est au final assez compliqué de toucher le public cible.