Des bêtas efficaces

a marqué ce sujet comme résolu.

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.

D'un autre côté écrire un article ou un tuto est déjà extrêmement chronophage. Passer encore le double du temps en explications et en détaillant point par point chaque commit, avec en plus des kilomètres de discussion, pour un auteur, c'est bien quand il a tout le temps pour ça, mais quand il s'agit d'une pratique bénévole c'est trop.

C'est justement l'objet de ce thread de définir quoi commenter quand on est en bêta. Dans mon cas c'est très simple : je suis pas sûr de bien avoir compris ça est l'info qui me sert le plus.

Je vois qu'il sort de toutes les interventions une autre guideline hyper importante : les corrections orthographiques ou de typo c'est à la fin. Et c'est logique : ça ne sert à rien de perdre du temps sur l'orthographe et la grammaire d'un paragraphe en cours de rédaction puisqu'on ne sait même pas s'il ne sera pas complètement récrit le lendemain.

+2 -0

Juste un point à prendre en compte : lire un tuto complet, c'est long. Devoir le relire juste pour traquer les fautes, quand l'auteur aura décidé que ça va comme ça, ça peut être particulièrement chiant. Accessoirement, on est moins efficace quand on corrige un texte qu'on a déjà lu.

Tout ça pour dire que quand je ne vois pas vraiment de problème majeur sur le fond, et que les gens qui sont passés avant moi n'ont rien relevé de critique non plus, quand il y a donc une forte probabilité que le texte reste globalement en l'état, je poste les corrections orthotypo sans attendre, parce que je n'ai pas envie de me fader une deuxième lecture juste pour l'orthographe.

TL;DR : les relecteurs aussi sont bénévoles.

+3 -1

Juste un point à prendre en compte : lire un tuto complet, c'est long. Devoir le relire juste pour traquer les fautes, quand l'auteur aura décidé que ça va comme ça, ça peut être particulièrement chiant. Accessoirement, on est moins efficace quand on corrige un texte qu'on a déjà lu.

Tout ça pour dire que quand je ne vois pas vraiment de problème majeur sur le fond, et que les gens qui sont passés avant moi n'ont rien relevé de critique non plus, quand il y a donc une forte probabilité que le texte reste globalement en l'état, je poste les corrections orthotypo sans attendre, parce que je n'ai pas envie de me fader une deuxième lecture juste pour l'orthographe.

TL;DR : les relecteurs aussi sont bénévoles.

Dominus Carnufex

Eh bien ne te tape pas de deuxième lecture tout court dans ce cas, quelqu'un d'autre le fera…

Dans mon cas perso, vu que je bosse sur git, prendre de temps en temps une liste de typos ne me dérange pas, je la colle dans un coin et… je l'oublie parce que j'ai la flemme de devoir faire mentalement le diff entre ce qui était écrit quand elle a été relevée et ce qui a bougé dans le texte entre temps. Et ça c'est en mettant de côté le fait que des gens font parfois des pull-requests de corrections ortho.

Du coup je me retrouve à me faire ou merger des commits de corrections orthographiques alors que je ne sais toujours pas si le texte va rester en l'état ou pas, et je me retrouve obligé de les faire tout de suite tant qu'il est encore possible de tirer quelque chose de ces retours.

TL; DR: Le problème, c'est qu'une liste de corrections de typos qui arrive en début de rédaction n'est plus exploitable lorsqu'on passe en phase de correction. Alors dans ce cas, autant ne pas en faire que d'en faire une trop tôt.

+2 -1

Personnellement j'veux bien discuter mais commits pullrequests merge et gît machin je n'y connais rien… Alors si on pouvait mètre juste une annotation pour traduire ce que ça veut dire ce sera cool.

+0 -0
  • un commit : c'est une modification du contenu, en gros, ça revient à une "sauvegarde".
  • pull-request : quand quelqu'un d'autre que l'auteur veut modifier le texte, il fait plusieurs commits de son côté et propose ensuite ceux-ci à l'auteur. Cette proposition s'appelle une pull-request. L'auteur peut l'accepter (donc faire un merge, c'est-à-dire "fondre" sa version du texte et l'autre ensemble) ou la refuser.
+1 -0

Et les pull-requests peuvent être acceptés partiellement ? Ou il faut un faire un par proposition de correction ?

Et du coup, je ne vois pas trop où tu veux en venir. Tu dis plus ou moins que sur git non plus, des corrections orthoagraphiques trop tôt ne sont pas souhaitables, donc exactement la même chose qu'ici. Ou ai-je mal compris ?

Ah merci, c'est pas mal. Mais c'est un système lié à GitHub non ?

Quoiqu'il arrive avoir plusieurs proposition (ou pull-request) c'est pénible à gérer; Soit on a des beta-lecteurs ordonné sur nos méthodes perso' (celle qu'on a chacun citées individuellement ici) et on peut se débrouiller au mieux (ça peut leur compliquer la tâche d'une manière assez dur). Et on re-édite (ou merge) dans l'ordre d'importance, Plan, Pédagogie, Fond, Forme

+0 -0

Et les pull-requests peuvent être acceptés partiellement ? Ou il faut un faire un par proposition de correction ?

Une proposition par correction

Et du coup, je ne vois pas trop où tu veux en venir. Tu dis plus ou moins que sur git non plus, des corrections orthoagraphiques trop tôt ne sont pas souhaitables, donc exactement la même chose qu'ici. Ou ai-je mal compris ?

Rockaround

Je répondais à Dominus qui disait en substance "ouais mais je vais pas relire un texte 15 fois pour les corrections orthographiques alors tant pis si c'est mieux de les proposer à la fin moi quand je relis je sors une liste et basta".

Et j'expliquais pourquoi il valait mieux ne pas perdre de temps à proposer ces corrections ou ces listes de typos plutôt que de les faire trop tôt : les faire trop tôt, c'est forcer l'auteur à incorporer ces modifs tout de suite alors qu'on ne sait même pas si le texte concerné sera encore là dans la version finale, parce qu'à la fin il devient trop laborieux de déterminer si une erreur relevée fait partie d'un bout de texte encore présent, ou déjà corrigé, ou non. Donc c'est une perte de temps, à la fois pour l'auteur et pour le relecteur.

Qu'il s'agisse de listes sur un sujet de bêta ou de pull-requests ne change rien au fait que c'est mieux de faire des passes orthographiques à la fin. J'ai parlé des PR simplement parce que certains relecteurs en font sur mes articles et que je trouve dommage qu'ils passent du temps à les faire au mauvais moment.

+1 -1

Je répondais à Dominus qui disais en substance "ouais mais je vais pas relire un texte 15 fois pour les corrections orthographiques alors tant pis si c'est mieux de les proposer à la fin moi quand je relis je sors une liste et basta".

Ah non mais ça me troue le cul de lire ça… C'est bien ce qui me semblait, tu n'as lu que ce qui t'arrangeait. C'est pourtant pas faute d'avoir été explicite…

quand je ne vois pas vraiment de problème majeur sur le fond, et que les gens qui sont passés avant moi n'ont rien relevé de critique non plus, quand il y a donc une forte probabilité que le texte reste globalement en l'état,

moi

Une putain de ligne et demie, c'est vrai que ça passe inaperçu…

+1 -2

Je répondais à Dominus qui disais en substance "ouais mais je vais pas relire un texte 15 fois pour les corrections orthographiques alors tant pis si c'est mieux de les proposer à la fin moi quand je relis je sors une liste et basta".

Ah non mais ça me troue le cul de lire ça… C'est bien ce qui me semblait, tu n'as lu que ce qui t'arrangeait. C'est pourtant pas faute d'avoir été explicite…

quand je ne vois pas vraiment de problème majeur sur le fond, et que les gens qui sont passés avant moi n'ont rien relevé de critique non plus, quand il y a donc une forte probabilité que le texte reste globalement en l'état,

moi

Une putain de ligne et demie, c'est vrai que ça passe inaperçu…

Dominus Carnufex

Ça ne change pas grand chose.

Prenons un exemple concret. Tu es venu sur la bêta de mon article sur la programmation asynchrone faire une relecture (et je t'en remercie beaucoup !). Tu as relevé pas mal de choses, de fond et de forme, que j'ai incorporées immédiatement.

Une semaine plus tard, la totalité du texte sur lequel tu étais intervenu avait été entièrement remanié.

C'est dommage, non ?

Toutes les corrections orthographiques que tu m'avais soumises ont été remplacées par autre chose, par contre les remarques de fond m'ont beaucoup aidé et sont restées.

+2 -0

peut-être faudrait-il mettre des phases de Beta ?

1er jet

Ce que je propose est de faire une sorte d'icone qui dirais si on a un tutoriel presque vide, style plan, à peine plus. A ce moment l'auteur tâte le terrain pour voir si ça plait, si cette structure est bonne, si d'autre veulent le rejoindre

Dans ce temps précis, on acceptera toutes les questions sur la profondeur d'analyse, jusqu'où va le tutoriel ? et quelles point y seront abordés.
Et durant cette période seul les gens intéressés par le sujet, néophytes ou aguerrie viendraient voir le sujet pour l'étudier avec l'auteur.

Pedagogie, Justesse

Dans la phase de préparation qui s'en suit, on devrait sortir un contenu pédagogique (c'est le minimum attendu) avec aussi une certaine qualité sur le fond. On ne fait pas QUE vulgariser. Le tutoriel est en bonne route les parties finies dès lors sont (d'après l'auteur) bouclées.

C'est là qu'intervienne indépendamment les néophytes et confirmés pour donner leurs opinions sur le fond et la méthode d'enseignement.

Un néophyte pourrait souligner un texte dur à comprendre, ainsi qu'un confirmé pourrait donner une meilleure manière (ou une deuxième) de montrer les choses. Le point de vue étant important

NB : les néophytes ici, je parle du publique cible hein

Orthographe

Donc le fond est revu durant cette période. Et enfin on passe en mode : Chasse aux fautes. par exemple c'est là que Vayel/Dominus Carnufex pourraient intervenir sur n'importe quel tutoriel :) Et vous le sauriez grâce à cette icone.

Je propose ça, mais ce n'est peut-être pas la meilleure chose. Malgré que je trouve l'idée sympatosh'

+4 -0

Ce qui est important c'est que les correcteurs compétent comme Vayel et Dominus Carnufex puissent réagir sur un tutoriel sans avoir besoin de s'y connaitre, puisque le fond serait déjà delimité et considéré comme bouclé.

J'imagine que les correcteurs vont plus sur les tutoriels où ils ont un petit goût de déjà-vue ou de curiosité. Mais dans ce cas ils s'embetteraient peut-être à corriger trop tot. Ou alors à devoir corriger deux fois ce qui est penible.

Note Importante : quand on fait un tutoriel bien compliqué et qu'on se relit sans cesse. C'est désagréable de connaitre par coeur chaques phrases ? Bah imaginez pour ceux qui doivent trouver des fautes alors qu'ils ont déjà lu un partie du tuto… C'est écœurant et on peut le comprendre.

Ce que je propose, c'est donc un partage des tâches

+0 -0

Une semaine plus tard, la totalité du texte sur lequel tu étais intervenu avait été entièrement remanié.

C'est dommage, non ?

C'est indubitablement dommage. Mais ce que j'essaye d'expliquer, c'est que ton exemple est l'exception qui confirme la règle. Je ne fais pas de correction orthotypo sur un tuto dont le fond est à revoir. À titre personnel, j'ai même tendance à ne tout simplement pas regarder les bêtas qui annoncent « le fond va sûrement beaucoup changer ». A contrario, il est très rare que les bêtas où je fais une correction complète changent substantiellement.

Tout ça pour dire que, même si la méthode actuelle a quelques ratés, c'est plus emmerder les relecteurs qu'autre chose que d'exiger d'eux qu'ils ne fassent leurs corrections qu'au dernier moment, dans tous les cas, sans exception. Et vu le peu de relecteurs qualifiés et motivés qu'on a sur le site, ça ne me paraît pas très judicieux de leur mettre des bâtons dans les roues… ;)

EDIT @Blackline : je ne vais pas parler au nom de Vayel, mais en général, je ne corrige que les tutos qui me plaisent, sur le fond. Je m'explique : corriger un texte, c'est fatigant, pas du tout gratifiant, et ça donne des ulcères quand on tombe encore une fois sur quelqu'un qui ne fait pas la différence entre « soi » et « soit ». Du coup, pour garder la motivation, ça m'aide quand j'ai envie que le tuto soit publié et bien propre. D'où le fait que j'agisse majoritairement sur des tutos qui collent avec mes goûts. Alors forcément, je ne peux pas introduire de distinction nette entre les tutos où je ferai des remarques sur le fond, et ceux où je ferai des remarques sur la forme.

+0 -0

La difficulté c'est surtout de savoir placer la barre. Si je reprends mon article en cours de rédaction j'ai ressenti le besoin de le refondre quand je me suis aperçu que Vayel butait sur des détails dans les derniers exemples à cause de notions qu'il n'avait pas retenues des premiers.

En me creusant la tête, j'ai pu déterminer que le problème était un mauvais dosage des détails : les points importants n'étaient pas assez détaillés et prépondérants dans le texte et les petits trucs sans importance l'embrouillaient (c'est aussi pour ça que je dis que c'est à l'auteur et pas à un relecteur neophyte de déterminer pourquoi il n'a pas compris).

Mais avant de me rendre compte de ce problème l'article avait l'air fini.

Au final je ne suis pas pour forcer les gens à soumettre ou non tel type de remarque et définir un processus rigide, même si c'est pas mal que tout le monde ait une idée de quelles remarques seront les plus utiles à tel ou tel moment de la rédaction.

+1 -0

@Dominus Et bien au moins avec une méthode comme celle-ci tu pourras rapidement te rendre compte des tutoriels où tu pourrais interagir sur la forme uniquement. :)

EDIT : Ajout du destinataire

+0 -0

Justement j'expliquais que c'était pas aussi évident que ça puisque le texte était déjà passé de facto en phase de correction orthographique au moment où je me suis aperçu qu'il y avait un problème de fond.

+1 -0

Nohar il ne fallait pas le prendre pour toi lol.

Alors pour ce qui est des problèmes de fond de dernière minutes. Ça m'est aussi arrivé (un mini-tuto qui s'est vue transformé en Big-tuto pour cause d'une introduction trop courte). Ce que ça implique généralement c'est que ces gens veulent faire des remarques pertinentes pouvant ébranler toute la structure d'un tutoriel. Pour son bien ! :)

Je pense que c'est inévitable et que bien heureusement : l'envie vicérale des gens n'ayant pas compris un tutoriel ou te proposant de le remanié, ne sera pas stoppable par une simple icone "on s'occupe de l'orthographe en ce moment même".

A n'importe quel moment les remarques sur la pédagogie, justesse sont bonnes à prendre. Même après validation. Donc cela fait partie pour moi de la magie du site : On peut toujours faire mieux. Donc nous ne seront jamais à l'abris Nohar :p

+0 -0

Je pense qu'on se prend la tête pour pas grand chose : rajouter des pictogrammes, faire un guide… je ne trouve pas ça utile. Chaque auteur a des besoins particuliers, qui ne peuvent pas rentrer dans des cases. Donc c'est à lui de dire ce qu'il recherche, dans le premier message. S'il ne précise rien, ben tant pis, il aura tous les retours que veulent bien lui faire les relecteurs. C'est à l'auteur de dire s'il trouve son tuto est assez mûr pour se focaliser enfin sur l'orthographe. Et même s'il ne dit pas qu'il veut un retour sur le plan, on peut toujours le dire si on pense que celui-ci est améliorable…

Donc c'est à lui de dire ce qu'il recherche, dans le premier message. […] C'est à l'auteur de dire s'il trouve son tuto est assez mûr pour se focaliser enfin sur l'orthographe. Et même s'il ne dit pas qu'il veut un retour sur le plan, on peut toujours le dire si on pense que celui-ci est améliorable…

Looping

C'est beau en théorie. En pratique, les lecteurs ne tiennent pas spécialement compte de ce premier message – c'est un fait, c'est comme ça depuis les débuts de la bêta, déjà sur le Site du Zéro. Par exemple je peux dire qu'il n'y a que la première partie et que j'attends des retours sur le concept et le traitement du sujet, et recevoir 3 réponses plein de remarques orthographiques. Forcément, puisque le texte n'a pas été vraiment relu…

Je ne jette la pierre à personne, mais le fait est que les demandes dans le premier message, ça ne fonctionne pas et n'est pas suffisant.

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