Perspectives d'évolutions du système éditorial

Est-ce qu’il serait possible d’obtenir quelques indicateurs statistiques sur le caractère attractif ou repoussant de notre système, en examinant l’évolution, sur les dernières années :

• Du nombre de contenus envoyés à la validation,
• Du nombre de contenus qui ont été validés,
• Du nombre d’auteurs distincts qui ont envoyé des contenus à la validation,
• Du nombre d’auteurs distincts dont le contenu a été validé ?

Je n’ai pas accès à la base, mais avec deux trois lignes de commande et un tableur, j’ai pris 15 minutes pour obtenir des données approximatives sur le nombre de contenus validés (le reste est plus compliqué à obtenir vite-fait). Risque de doublon, même si les cas évident sont gérés (date dans le titre, par exemple), et j’ai vérifié vite-fait certaines données à la main (on a bien 64 articles en 2015, c’est pas une erreur) :

On parle de collecter des données pour voir comment améliorer les choses, mais je ne suis pas sûr qu’on va apprendre grand chose de plus que ce que l’on sait déjà : le système actuel est lourd et peu engageant. Il y a par ailleurs des données précieuses qui nous manquent : on ne sait pas ce qui se passe si on change de système de validation parce qu’on n’a jamais essayé. De la façon dont cette discussion est partie, on va faire comme d’habitude et débattre un peu dans le vide pendant des pages de comment mettre au point un bon système sans jamais aboutir à déjà essayer quelque chose de différent. On a déjà une idée qui se profile, si on essayait ça et qu’on fabriquait des données réelles sur ce qui se passe effectivement au lieu de théoriser sur ce qui pourrait se passer à partir d’observations biaisées par le fait que le seul système qu’on n’a jamais observé est l’actuel ?

Ces données permettent quand même de casser cette idée que malgré sa lourdeur, le système fonctionne.

Oui enfin ça c’est pas nouveau qu’il ne fonctionne pas. Comme tu dis toi même, ça fait 10 ans que tu le sais, ça fait 7 ou 8 ans que je le sais aussi. On a parlé plusieurs fois de le changer parce qu’on sait surtout à quel point c’est lourd pour tout le monde (et pourtant je ne pense pas qu’on ait de données mesurées proprement avec des jolis graphes dans 4 espaces de paramètres différents pour nous dire ça !).

La vraie question pertinente, celle qui nous intéresse et qui a du sens, c’est de savoir si malgré sa lourdeur, c’est le mieux qu’on puisse faire pour remplir nos objectifs. J’espère que non, et la seule façon de le savoir est de tester d’autres systèmes.

Pour moi, l’idée proposée ne va aider à la publication des contenus (pas plus de retours, retours plus tardifs), tout en polluant les billets, rendant un système déjà obscure encore moins claire.

Tu as des données qui supportent cette théorie ?

On est pile dans le travers habituel, on débat dans le vide. On a vu par le passé qu’on savait faire ça très bien et que ça ne va nulle part. On n’a pas encore essayé d’essayer un truc pour voir ce que ça donne. Ça parait une façon d’avancer qui sera a minima aussi productive (i.e. pas du tout) que débattre pendant des pages.

Sur l’interface de relecture, moi j’aime bien les interfaces de "review" à la Github/Gitlab: on peut commenter en direct au milieu du texte, et avoir des conversations sur des bouts (en plus de conversations d’ensemble dans un fil de discussion global). Idéalement (c’est une idée qu’on avait déjà proposée au SdZ) on pourrait stocker les tutos dans un dépôt git, et (optionellement, en alternative à une interface clicodrome sur le site) soumettre de nouveaux tutos par une forge git moderne. Les validateurs lisent une version pré-rendue du document (générée par un bot ou un mécanisme d’intégration continue, Gitlab le permet facilement par exemple), et commentent directement dans le source, comme pour une relecture de code.

C’est une façon de travailler qui peut poser un problème d’accessibilité, git étant un outil bien maîtrisé par les développeurs et méconnu du reste de la population. Mais ça peut s’expliquer, ça n’a pas besoin d’être la seule interface possible, et ça donne une interface agréable pour tout le monde en utilisant des outils existants, au lieu de devoir tout ré-implémenter côté ZdS.

Sur le volume de tutoriels soumis, il faudrait voir aussi le volume des billets, non ? Si les volumes de billets baissent aussi, on n’a pas montré un problème lié à la validation, mais une baisse du niveau global de soumissions. Et pour ça la "solution" passe par la communication, le fait de parler du site à des gens qui auraient envie de nous rejoindre et de créer des contenus.

Sur le volume de tutoriels soumis, il faudrait voir aussi le volume des billets, non ? Si les volumes de billets baissent aussi, on n’a pas montré un problème lié à la validation, mais une baisse du niveau global de soumissions. Et pour ça la "solution" passe par la communication, le fait de parler du site à des gens qui auraient envie de nous rejoindre et de créer des contenus.

Le volume de proposé à la validation a aussi baissé de ce que je constate. C’est sûr qu’il faut réinsister niveau com' sur l’écriture de contenus.

Je suis d’accord, mais j’ai quand même lu l’argument il y a peu

Et d’autre part, pour moi avant de décider comment on veut améliorer le processus, il faut qu’on se mette d’accord sur où on veut aller.

Parce que si on est globalement d’accord pour dire qu’on veut, sur ZdS, du "contenu de qualité", on a aucune définition claire de "contenu" et de "qualité".

Tu as des données qui supportent cette théorie ?

Tu en as qui montrent que l’idée proposée ici va faire mieux ? Parce que passer au forceps et sans preuve un changement important dans le processus de publication et refuser de le discuter, ce serait gros quand même.

Car oui, parler de discuter des détails d’implémentation trois heures après le message orignal, et dire que sans preuve que ça marche pas, faut le faire, c’est tenter de passer au forceps.

Si tu veux une base qui à l’air de faire consensus, c’est le message de @SpaceFox sur la page précédente.

On parle de collecter des données pour voir comment améliorer les choses

Non, j’ai bien parlé de collecter les données pour décider de la nécessité de changer ou non. Et la conclusion que je tire de ces données, c’est que désormais, la position "ça fonctionne pas si mal, il suffit de recruter plus de validateurs" n’est plus recevable dans le débat à venir. De toute évidence il faut changer, et de façon efficace.

Mais évidemment ces données ne nous diront pas comment. Ça c’est l’objet du débat.

Tu en as qui montrent que l’idée proposée ici va faire mieux ?

Le point que je soulève est justement qu’on n’en a pas parce qu’on n’a pas essayé et qu’essayer quelque chose de nouveau, même si il s’avère que ça ne marche pas, constituerait déjà un premier pas dans l’espace des systèmes de validation. On va pas trouver l’optimum dans cet espace si on va jamais aller mesurer d’autres points.

Mais bref, si le consensus part encore sur une discussion de 10 pages pour débattre encore de la conception d’un nouveau système puis ne rien faire ensuite, soit.

Il y a quelques années, on avait fait un tour de la béta, et on avait relancé tous les auteurs encore présents sur ZdS. La plupart étaient partis, et chez ceux restant, la moitié ne voulait pas finir leur tuto, et l’autre avait abouti à publication. Deux ou trois de mémoire.

Des tutos qui ne passent pas la validation sont de mon expérience beaucoup plus rare que ceux qui meurent en béta. C’est pourquoi je dis que s’attaquer à la béta est un faux problème : il faut accompagner au plus près les auteurs. Je proposais un système de validateurs attribués dès la béta. Plus de taff, mais il semble que ce ne soit pas le facteur limitant aujourd’hui, mais un meilleur suivi qui devrait lever un gros frein. Et pour ça, mieux utiliser la béta pourrait marcher.

La béta a toujours était dans l’angle mort de la validation. Pas de suivi officiel, personne pour dire aux nouveaux « je suis validateur, n’hésite pas à me poser des questions » ; on attendait souvent que le tuto arrive en validation pour réagir. Moi le premier ; je lisais moins les bétas quand j’étais validateur qu’avant de l’être.

La supprimer au profit des billets va rendre encore plus compliqué ce suivi, déjà très mauvais. Soit tu considères que le suivi n’est pas un problème actuellement, ou qu’il est moins important que d’autres points que tu espères corriger en transformant la béta en billet, soit tu considères que le suivi sera meilleur avec les billets. Si c’est ça : pourquoi, comment ?

Le système ne marche plus (il n’a jamais marché efficacement, mais on arrive ou bout du bout), et la question est comment l’améliorer ou le repenser complètement. Changer la manière d’utiliser la béta me semble plus intéressant que de la supprimer de mon expérience.

Pour moi, les données montrent que toutes les catégories mesurées voient une baisse de soumissions importantes sur 2019–2020. Mais elles ne permettent pas de dire si c’est spécifique à ces catégories, ou si ça touche tout le site. Si on veut dire qu’on prend des décisions sur des données, autant commencer par les analyser sérieusement, en essayant d’éliminer les corrélations qui plomberaient l’analyse.

Est-ce qu’on pourrait avoir des données sur le volume des discussions sur le forum, le nombre de visites de membres abonnés, les soumissions de billets, le nombre de nouveaux abonnements ? Si tout baisse, ça ne veut pas du tout dire la même que si seulement certaines parties baissent.

Peut-être qu’on devrait réfléchir à des solutions techniques très pragmatiques. Une sorte de trello pour tous les contenus qui commencent une bêta. Qu’on puisse facilement visualiser l’ensemble de la production en train de se faire

Mais évidemment ces données ne nous diront pas comment. Ça c’est l’objet du débat.

On sait déjà que débattre n’aboutit à rien de concret, on peut aussi changer de tactique et essayer.

Je proposais un système de validateurs attribués dès la béta. Plus de taff, mais il semble que ce ne soit pas le facteur limitant aujourd’hui, mais un meilleure suivi qui devrait lever un gros frein. Et pour ça, mieux utiliser la béta pourrait marcher.

C’est une idée, et si t’es plus comfortable avec celle-là qu’une autre, très bien, c’est un argument comme un autre. On n’aura pas d’élément concluant tant qu’on essaye pas. Il va falloir plus de valido par contre, parce que c’est beaucoup plus de taf. Et actuellement, les membres actifs sont quasiment tous staff ou ex-staff. Ça va pas forcément être facile de trouver une large équipe, mais on peut essayer.

Est-ce qu’on pourrait avoir des données sur le volume des discussions sur le forum, le nombre de visites de membres abonnés, les soumissions de billets, le nombre de nouveaux abonnements ? Si tout baisse, ça ne veut pas du tout dire la même que si seulement certaines parties baissent.

C’est difficile de décorréler proprement, on peut très bien imaginer que si tout baisse, c’est parce qu’on valide pas assez de nouveaux contenus. Si tout est mesuré à système de validation constant, on peut rien déduire sur le système de validation. C’est bête comme choux.

C’est difficile de décorréler proprement, on peut très bien imaginer que si tout baisse, c’est parce qu’on valide pas assez de nouveaux contenus. Si tout est mesuré à système de validation constant, on peut rien déduire sur le système de validation. C’est bête comme choux.

Donc les messages ci-dessus sur le fait d’utiliser des données pour prendre des décisions, ce n’était pas sérieux, si on ne veut interpréter les données qu’après avoir fait des changements ? (Et euh, si on a 1–3 tutos validés par mois en moyenne, il faudra attendre combien de temps pour avoir des données fiables pour évaluer le changement ?)

Donc les messages ci-dessus sur le fait d’utiliser des données pour prendre des décisions, ce n’était pas sérieux, si on ne veut interpréter les données qu’après avoir fait des changements ?

Je ne sais pas à quel message tu fais effectivement allusion, mais clairement on ne peut pas dire grand chose d’intéressant sur le système de validation actuel tant qu’on n’a pas essayé autre chose pour comparer. On sait que le système actuel est lourd pour les auteurs et les validateurs. Ce qu’on ne sait pas et on n’a aucune donnée là-dessus, c’est si il existe un/des système(s) de validation meilleurs (i.e. plus efficients) que l’actuel sur cet aspect qui ne sacrifient pas la qualité du contenu (qui reste à définir comme mentionné par @SpaceFox, mais j’ai l’impression que c’est encore un autre débat).

Des tutos qui ne passent pas la validation sont de mon expérience beaucoup plus rare que ceux qui meurent en béta. C’est pourquoi je dis que s’attaquer à la béta est un faux problème : il faut accompagner au plus près les auteurs. Je proposais un système de validateurs attribués dès la béta. Plus de taff, mais il semble que ce ne soit pas le facteur limitant aujourd’hui, mais un meilleur suivi qui devrait lever un gros frein. Et pour ça, mieux utiliser la béta pourrait marcher.

J’avais émis l’idée il y a quelques mois de le faire encore plus tôt : dès la création du contenu (voir sur le forum).

On sait déjà que débattre n’aboutit à rien de concret, on peut aussi changer de tactique et essayer.

@adri1 ah, mais là tu prêches un converti. Si ça ne tenait qu’à moi, ça ferait longtemps qu’on aurait mis en place une bonne partie des trucs décrits dans le post originel, sans pour autant les graver dans le marbre, pour en mesurer l’effet, et peut-être qu’on aurait même eu le temps de faire machine arrière ou bien qu’on serait en train de discuter d’une seconde ou d’une troisième itération en fonction de ce que l’on a observé.

À un moment donné, il faut aussi garder en tête que ce qui fait la qualité de ZdS, ce n’est pas tant les garde-fous ni les restrictions mises en place par construction sur le site, que la bonne volonté, l’énergie et la qualité de sa communauté : on peut avoir le système qualité le plus ingénieux du monde, sans une communauté qui a envie de participer, on n’a rien. Et parfois ça repose uniquement, bêtement, humainement, sur l’enthousiasme de la nouveauté.

Au plus profond, ce que je pense en lisant ces pages, c’est que l’on manque cruellement de confiance en notre communauté au point de pousser l’aversion au risque à son maximum, à devoir discuter 10 pages pour ne jamais rien tenter.

Et au plus profond, je pense que c’est ça qui risque le plus de nous tuer.

Edit : autrement dit, en demandant plus haut des données, j’espère surtout pouvoir amener les gens à prendre conscience qu’il est temps de bouger. Parce que la stratégie "ne rien faire" qu’on applique depuis des années n’empêche pas notre santé de se dégrader.

Petites propositions qui me semblent intéressantes en lisant :

• L’apparition des bêta sur la page d’accueil. Une mise à jour de la bêta fait remonter le contenu en haut de la liste. Il faudrait sans doute une validation à priori comme pour les billets.
• Le système de commentaires, très nécessaire
• Une interface de rédaction plus légère mais aussi plus souple. Je pense à la distinction petit/moyen/big tuto à supprimer et fonctionner en parties de différents niveaux que l’on puisse modifier dans l’ordre mais aussi le niveau hiérarchique (idéalement en glisser-déposer, mais avec des boutons aussi puisque plus simple j’imagine)
• la possibilité de contacter directement les casquettes, peut-être, ce qui créerait un MP avec les personnes concernées et permettrait de contacter directement la validation

Je suis favorable à la proposition de Gabbro sur l’implication de la validation au plus tôt (personnellement, c’est probablement ce dont j’ai besoin).