Des bêtas efficaces

Oyez oyez !

Je vous propose aujourd'hui de réfléchir à la manière de rendre les bêtas (des tutoriels et articles) efficaces. Pour ce faire, j'invite les contributeurs à participer en indiquant (ici, hein, pas dans les sujets des bêtas : on n'en est qu'à la phase de réflexion) :

• quels types de retours vous recherchez, si vous êtes auteur ;
• quelles informations/consignes vous souhaitez recevoir de la part de l'auteur, si vous êtes relecteur.

On pourra alors comparer les modes de fonctionnement de chacun, non pas pour en construire un optimal (en supposant que ce soit possible…) à suivre obligatoirement, mais pour remettre en question sa manière de travailler, tout simplement.

Notons que l'objectif n'est pas, pour les relecteurs, de recenser les conseils que les auteurs devraient suivre : on ne se demande pas comment écrire un contenu, mais comment le commenter.

Merci !

PS : je posterai mon point de vue de relecteur plus tard.

En temps qu'auteur, j'utilise la béta en deux temps : d'abord pour le fond, ensuite pour la forme. Le fond, c'est aussi bien les informations contenus dans l'article (sont-elles justes et compréhensibles) que savoir si le public visé est effectivement la public atteint. Ça donne des « consignes » du genre :

Il s'agit d'une première version publique. Donc les retours orthographique ne sont pas encore pertinent (j'ai fait le minimum : correcteur auto de grammaire et d'orthographe, pas encore de relecture manuelle). L'article n'est pas encore fini.

N'hésitez en aucun cas à donner votre avis, que ce soit sur des phrases un peu bizarre, sur des trucs pas clairs, voir faux ( ), ou sur quoi que ce soit qui vous passe dans l'esprit.

Dans un second temps, je demande des retours plus variés, y compris sur l'orthographe.

L'avantage, c'est que ça évite de corriger des fautes sur des phrases qui vont disparaître, ce qui est une perte de temps aussi bien pour l'auteur que pour le relecteur. L’inconvénient, c'est qu'il y a assez peu de relecteur lors de la deuxième passe (logique, relire un texte déjà lu juste pour corriger les fautes, c'est chiant).

En temps que relecteur, j'essaie de découper mes commentaires en trois parties : le fond (comme précédemment) et, si le fond est bon, le style (phrase ambiguë, par exemple) et l'orthographe. Après, c'est assez variable et dépend aussi pas mal du sujet et du temps dont je dispose au moment où je relis.

Salut,

En tant qu'auteur, du plus fondamental au plus anecdotique, j'aime avoir des retours sur ce qui suit, dans cet ordre. Alors dit comme ça, ça fait un peu rigide, mais en fait ça fait gagner du temps à tout le monde, parce qu'en général, rien ne sert de corriger le style si le fond est mauvais, ou encore l'orthographe si des améliorations de style amènent à changer des paragraphes entiers.

Thème, cible, objectifs

• Le public cible est-il bien choisi ?
• Le sujet n'est-il pas déjà parfaitement traité pour ce public ailleurs ?
• Sinon, que manque-t-il qui pourrait apporter une valeur ajoutée ?
• Les objectifs et prérequis sont-ils adaptés à la cible ?

Ces questions, je me les pose aussi personnellement, mais un apport extérieur est toujours le bienvenu pour faire mûrir la réflexion. Cela permet souvent d'éviter d'écrire un texte qui n'intéresse personne, ou qui est dominé par d'autres contenus mieux faits en tous points.

Fond

• Le contenu répond-il aux objectifs ?
• Certains éléments sont-ils superflus par rapport aux objectifs ?
• Y a-t-il quelque chose dont il faut absolument parler, et qui n'est pas dans le plan ?
• Y a-t-il des erreurs factuelles ou des simplifications abusives ?

Donner un retour sur ces questions permet de savoir si on va effectivement répondre aux objectifs avec notre contenu, et être sûr de rien oublier d'essentiel, qui rendrait la qualité instantanément moins bonne.

C'est aussi un bon moment pour donner des idées du type, "parle de ça, je trouve que c'est trop rigolo/formateur/impressionnant".

Style

• Les explications sont-elles brèves, claires, et précises ?
• Le style général est-il fluide ?
• Y a-t-il des illustrations si nécessaire ?
• etc.

L'idée, c'est d'avoir la forme la plus efficace et pédagogique possible, en évitant trop de fioritures (sans forcément sombrer dans le morne hein !).

Grammaire, orthographe, présentation

• Aider à identifier les fautes de syntaxe, grammaire, orthographe, et orthotypographie (dans cet ordre).
• Qualité des schémas / photos.
• Des idées de bon titre et d'accroche

Bon pour l'orthographe, c'est évident, mais je pense que les schémas sont aussi importants, et devraient être au moins aussi soignés.

Ce que j'aimerais avoir comme retour, c'est que les lecteurs m'indiquent les passages où ils ont eu des difficultés : à quel endroit du cours (dans le plan) ceux-ci ont eu du mal à comprendre quelque chose, et si possible pourquoi. Ce genre de retour me parait primordial, mais je dois avouer que je n'en ai pas très souvent : quand on me signale des problèmes de compréhension, c'est souvent sur point précis, dans une phrase par exemple, mais pas dans une portion plus grande comme un extrait, un titre1, un chapitre, etc.

C'est clairement aussi important que les erreurs de fond ou de forme, et ça devrait passer en priorité. Premièrement, ça ne sert à rien de corriger les fautes d'orthographe ou les erreurs de fond dans un chapitre que la moitié des lecteurs ne lira jamais car il a abandonné aux chapitres précédents (sauf pour des erreurs de fond vraiment graves qui peuvent causer de lourdes refontes des explications ou du plan de cours). Et si je dis cela, c'est surtout parce que sur certains gros cours que j'ai écris, je n'ai des retours que sur les premiers chapitres et pas les autres, et que je suppose que c'est parce que les lecteurs abandonnent avant. Deuxièmement, à quoi bon corriger des erreurs dans un extrait qui sera refait de fond en comble s'il n'est pas assez pédagogique ?

Personnellement je vois dans la Beta plusieurs phases qui ne doivent pas se chevaucher pour être utile :

Plan : 1er jet

Je pense qu'il serait très pratique de pouvoir ouvrire une Beta pour simplement présenter un plan. Et ainsi obtenir un retour dessus. Ca serait à mon avis la première étape d'une beta qui reponderait à la communauté. Cela permet au plus néophytes d'entres-nous de pouvoir avoir un premier avis de la part de ses potentiels pairs. Ensuite cela peut-être la phase de recrutement. Un projet neuf "pop" alors de potentiels co-redacteurs peuvent venir pointer le bout de leur nez. (Sans pour autant qu'on puisse appeler ça une Beta, puisque ce n'est qu'un plan voir un meta-plan)

Pedagogie : Le retour de néophytes

Dans un deuxième temps, après avoir commencer à rediger j'aimerais que les retours s'orientes vers le parcours de lecture. Comme Mewtow j'aimerais avoir des retours sur la comprehension du propos. Et/ou si les phases complexes ne sont pas assez longues. Aussi le rythme de lecture peut-être revu pour avoir une meilleure qualités finale (Même si c'est très dur de s'accorder la dessus)

La Justesse : Le point de vue des experts

Une fois la partie vulgarisation ou explications au point, on peut enfin se permettre d'être tatillons, et ainsi de demander aux personnes plus qualifiés (ou tout autant) de donner leurs avis sur le fond du sujet. Je pense que ça doit se faire après l’étude pédagogique car des fois lorsque l'on vulgarise on ment.

Orthographe

Et surtout, please, s'il vous plait, bitte, toussa², l'orthographe en DERNIER. Une beta où nous ne sommes pas sur de voir tout les paragraphes produits être publié, ce n'est pas utile de la corriger. Par contre les erreurs syntaxique à la rigueur rejoigne l'idée de pédagogie (si on ne comprend pas la phrase, bah c'est evident que nous ne comprendrions rien).

Je ne sais pas si pour autant cela peut s'appliquer au forum des Betas. Je pense que ce que je dis là est en parti HS et plutot de l'ordre du : Conseil

D'accord avec ce qui a été dit au-dessus. Ce que je rajouterai aussi, c'est, pour toutes les questions que se pose l'auteur et qui sont listées au-dessus, le relecteur doit aussi le dire s'il trouve que c'est bien fait : genre, j'aime bien la manière dont tu as présenté ça, le style est fluide, cet exemple est très parlant, ça correspond bien au public visé,… Sinon l'auteur ne sait pas si le lecteur trouve ça bien ou s'il n'y a pas fait attention.
Ca peut lui permettre de voir ce qui plait et d'améliorer en conséquence les autres parties par exemple.

Les personnes au-dessus ont plutôt bien listé ce que j'attends en tant qu'auteur d'une beta.

En tant que lecteur je m'attends à :

• ce que l'auteur dise où il en est ;
• ce qu'il veut qui soit relu ;
• ce qu'il cherche pour compléter la rédaction de la partie relue (si besoin) ;
• ce qu'il aimerait être étudié en profondeur (orthographe, définitions, démo, introduction de notions, etc.).

J'importe un peu le débat sur le dernier article publié. Ce serait en effet assez intéressant, pour les sujets qui ont un thème plus "social" (économie, histoire etc.), de chercher la petite bête dans les tournures de phrase pour ne fâcher personne inutilement. L'article en question n'avait pas eu particulièrement de retours sur ce point là en bêta, et en validation, c'est passé également inaperçu.

Bonne idée. Concernant les commentaires sur la forme, je trouve qu'il ne devraient à l'avenir plus être exprimés une fois l'article publié si la bêta est restée ouverte suffisamment longtemps.

Détail vite oublié : la vérification des liens morts. Mon tutoriel qui vient d'être publié à un lien mort à cause d'une erreur d'encodage passée inaperçue en bêta et en validation. C'est tellement facile d'oublier de cliquer un lien à la relecture, qu'un peu d'aide des bêta-testeurs serait efficace.

C'est aussi Arrivé à @dri1 sur sont tutoriel LaTeX ! +1 Aabu

Ce qui m'importe le plus sur une bêta, perso et de très loin, c'est que des débutants viennent poser des questions pour s'assurer qu'ils ont bien pigé.

En attirant mon attention sur les points obscurs, étant donné que je suis du genre à relire/récrire des dizaines de fois un paragraphe pendant que je rédige, ça me suffit en général à en déduire ce qui bloque (fond ou forme) et essayer autre chose.

Le plus important c'est vraiment le retour qualitatif du public cible qui me permet de déterminer si je colle à mon objectif ou non. Du reste je suis assez ours pendant la rédaction. Je préfère essayer 5 trucs différents mais à mon idée que d'appliquer directement les suggestions, c'est-à-dire analyser moi-même pourquoi le lecteur ne comprend pas plutôt que le lui demander directement. En particulier parce qu'un débutant qui n'a pas compris est certainement la personne la moins bien placée pour savoir pourquoi.

Je ne m'inquiète pas trop pour la justesse ou l'orthographe par contre. Parce que je ne rédige jamais sans avoir une doc ouverte sous les yeux, ni relire.

Par contre les commentaires sur le style sont importants.

C'est un autre problème, ça, c'est que le site sur lequel le lien pointait a changé d'adresse. Il était OK à l'époque.

Sinon, je cautionne particulièrement le point "orthographe en dernier". Je vois souvent dans les bêtas des gens qui font des listes kilométriques de petites corrections qui n'ont qu'un ordre syntaxique/grammatical/orthographique. Outre le fait que ça peut être une perte de temps pour ceux qui construisent de telles listes si le texte se barre après, ça casse pas mal la lecture du topic de la bêta en question… J'ai tendance à penser que pour ce genre de remarques, il faudrait utiliser le bouton "signaler une faute" en bas du tuto (évidemment, si celui-ci était plus accessible, visible et pratique, ce serait mieux, c'est sûr ), tout simplement parce que garder une trace de ces remarques dans la discussion bêta n'a aucun intérêt.

Je vais dire un truc un peu con, mais pour que les gens aident à la béta (en particulier les débutants) il faut qu'ils sachent qu'une beta existe, qu'ils peuvent participer et qu'ils viennent. Je ne sais pas si ces considérations entre dans le champ du débat actuel, mais pour moi c'est un des points principaux : faire connaitre le fonctionnement du site et inciter le débutant à participer (en le guidant) ce qui n'est pas le cas actuellement.

Sinon je suis d'accord pour dire que l'orthographe devrait venir en dernier.

Je penses que ça serait bien de proposer un systéme de notes, pour avoir des critères pour mieux comprendre comment un tuto est reçu du genre : - Le sujet vous intéresse-il ? - Avez vous des connaissances sur le sujet ? - Trouvez vous les explications des notions inconnues assez claires ? - Le tuto comporte-il assez d'exemples/illustrations pour comprendre l'utilité des notions abordées ? -Le plan vous semble-il cohérent ?

Bref, un certain nombre de questions où on pourrait mettre une note entre 1 et 10 et avec un tableau de bord qui donnerait à l'auteur une "carte" pour savoir comment son travail est vu avec des indicateurs pertinents.

On pourrait ainsi comparer les résultats de nos tutos à la moyenne des tutos pour avoir de idée de comment on se place par rapport aux autres.

Évidement au delà du soucis technique il y à le problème des notions évalués, mais je trouve que ça serait bien d'avoir une grille d'évaluation objectives et pas seulement des retours écrits! Ca permettra aussi à plus de monde de participer, juste en votant, ce qui est plus facile à faire que d'écrire un long commentaire !

Vous en pensez-quoi ?

[mode dream]
Pour éviter les "listes kilométriques" de petites corrections qui n'ont qu'un ordre syntaxique/grammatical/orthographique:
mettre en place un système d'annotations comme dans Google Drive ou Medium.com.
[/mode]

Le défaut de ce genre de systèmes, c'est que ta note, ça te sert à rien pour améliorer. Tu sais juste si c'est bien ou pas. Si c'est bien, tu sais pas pourquoi, et si c'est nul non plus. Du coup t'es pas vraiment avancé.

En fait techniquement l'interface que je préfère pour rédiger est github. Annotations ligne par ligne, issues, pull-requests ; peut-être une déformation professionnelle en fait…

Du coup t'es pas vraiment avancé.

Bha tu es au courant que y à un problème quelque part, ce qui est une première étape. Après en effet ça ne dit pas comment le réglé mais c'est une autre histoire. C'est déjà bien d'avoir l'info je trouve et de savoir sur quoi travailler.

Mais du coup tu ne sais pas comment le retravailler. Et puis quelqu'un qui vote "le plan n'est pas bien", autant qu'il l'écrive en disant pourquoi il trouve ça pas bien.
J'imagine bien un tuto de maths de niveau L1, et un collégien qui vote "les notions ne sont pas bien expliquées" par exemple.

@EtienneR : cadeau !

Concernant les relectures, il me semble que deux points n'ont pas été abordés :

• Les retours de l'auteur sur les remarques. Pour éviter les répétitions entre les passes de relecture, il est très appréciable de savoir précisément quelles remarques ont été prises en compte ou non (surtout ou non en fait). Encore mieux : pourquoi. En effet, on est tous là pour apprendre, et pour cela, rien de tel qu'une explication sur une proposition peu judicieuse.
• L'explication de l'auteur sur sa méthode de travailler. Par exemple, si j'ai bien compris ce message, il n'est pas très utile de faire des suggestions pédagogiques à nohar. Il est alors intéressant de le savoir ; sinon, le relecteur fait du travail en plus, que l'auteur n'apprécie même pas.

Faire des retours sur des remarques peut se révéler assez chronophage, du moins pour les micro-remarques liées à une phrase ou à une formulation malheureuse. Par contre, c'est essentiel pour les remarques importantes, qui portent sur des points plus généraux : l'idée qui se cache derrière une explication, la structuration du plan, l'approche utilisée, etc.