ZEP-20 : Relecture des tutos par les pairs

Objectifs

L'objet de cette ZEP est de discuter d'un nouveau système de validation des tutoriels. De telles discussions ont déjà été menées en interne, mais aucun consensus n'a été trouvé quant à l'évolution de la validation.

NB : les articles ne sont pas concernés par cette ZEP ; ils feront peut-être l'objet d'une proposition séparée.

Les objectifs à atteindre sont les suivants :

• faire en sorte que la validation sollicite moins le staff ;
• permettre à la communauté de s'impliquer davantage dans la validation ;

tout en conservant, le plus possible, les vertus du système de validation actuel :

• la validation est faite par des humains, qui fournissent un retour rédigé (en d'autres termes, la validation n'est pas un simple vote de la communauté) ;
• la validation est faite par des « experts » du domaine autant que possible.

Éclaircissement : Les problèmes de délais de validation rencontrés il y a quelques mois sont en train de se résorber, le Staff peut maintenant tenir le rythme de publication. L'idée de cette ZEP est plutôt de mettre la validation entre les mains de la communauté, tout en gardant le Staff en position d'arbitre et de coordinateur (afin d'éviter tout psychodrame). En d'autres termes, l'objectif est que l'efficacité de la validation scale avec la taille de la communauté, plutôt qu'avec la taille du Staff.

Solution proposée : validation par les pairs

Si vous venez du monde de la recherche, le titre de cette ZEP a du vous évoquer quelque chose. Je propose en effet d'adapter le système de relecture par les pairs à la validation de Zeste de Savoir. Pour comprendre comment cela fonctionne, suivons le cheminement d'un tuto.

1. Un auteur vient de finir d'écrire son tuto (après une phase éventuelle de beta). Il l'envoie à la validation.
2. Le Staff cherche, parmi les membres du site, des relecteurs pour ce tuto (environ trois). Ceux-ci sont des membres de confiance volontaires (ils peuvent refuser de relire).
3. Les relecteurs renvoient leurs commentaires au staff, avec une recommendation sur la décision (cf. ci-après).
4. Le staff, à la lumière des commentaires des relecteurs, prend la décision de validation ou refus. Dans tous les cas, il fait suivre les commentaires des relecteurs à l'auteur.

Détails de l'étape 2 : sélection des relecteurs

Le Staff choisit les relecteurs parmi les membres en qui il a confiance. En général, il sélectionne deux relecteurs « connaisseurs » du sujet et un relecteur « newbie » (selon le niveau du tuto). Tout membre peut refuser de relire un tuto, sans avoir à se justifier.

Le choix des relecteurs est discrétionnaire : le Staff se débrouille tout seul pour trouver des membres, il n'est pas possible de « candidater » pour devenir relecteur. Rassurez-vous : en pratique, nous n'avons jamais eu de problèmes pour trouver de membre compétent dans tel ou tel domaine lorsque nous en avions besoin ; nous connaissons suffisamment la communauté pour savoir à qui nous adresser.

Les relecteurs peuvent être des membres du Staff ou non. Pendant la phase de relecture, l'auteur ignore qui sont ses relecteurs, et les relecteurs ignorent qui sont leurs « co-relecteurs » sur un même tuto (dans la mesure du possible). L'objectif est d'avoir trois avis indépendants (pas de concertation), sans discussion préalable avec l'auteur (afin d'avoir des avis totalement extérieurs).

Détails de l'étape 3 : les relecteurs renvoient leurs commentaires

Chaque relecteur donne un avis sur le tuto, parmi :

• Refus fort (= « je souhaite que ce tuto ne paraisse jamais sur ZdS ») ;
• Refus simple (= « je souhaite que ce tuto soit amélioré avant de paraître sur ZdS ») ;
• Acceptation simple (= « pourquoi pas ») ;
• Acceptation forte (= « ce tuto est génial, prenez-le ! »).

En outre, chaque relecteur écrit une justification de son avis. En cas de refus définitif, il en explique les raisons ; en cas de refus simple, il précise quelles modifications sont nécessaires à la publication du tuto. De même, en cas d'acceptation, il décrit les raisons qui le poussent à accepter.

Détails de l'étape 4 : le Staff prend la décision finale

Enfin, le Staff récupère les avis et les commentaires, pèse le pour et le contre, puis prend la décision de valider ou de refuser le tuto. Cette décision n'a rien d'automatique : le Staff peut choisir de refuser un tuto qui a reçu trois « acceptations fortes ». Dans tous les cas, les avis et commentaires des relecteurs sont transmis à l'auteur. Si la décision du Staff est en contradiction avec les avis des relecteurs, il ajoute une notice expliquant sa décision.

Si le tutoriel est re-soumis après un premier refus (parce que des modifications étaient nécessaires, par exemple), les mêmes relecteurs sont sollicités pour prendre en charge cette nouvelle version du tuto. Ils peuvent, bien entendu, refuser, au quel cas de nouveaux relecteurs seront désignés par le Staff. Idéalement, les mêmes relecteurs suivent un tuto tout au long du processus de refus/modification/re-validation.

Par souci de simplicité et pour permettre des discussions au cours de l'amélioration du tutoriel, les commentaires des relecteurs ne sont pas anonymisés (à moins qu'ils en fassent la demande expresse). Nous faisons confiance à nos membres pour se comporter correctement et accepter sereinement la critique. En cas de débordement, le Staff jouera le rôle de modérateur, comme d'habitude.

Problèmes potentiels et leurs solutions

Il est impossible de prédire tous les problèmes que ce système peut poser. Toutefois, nous pouvons en anticiper certains.

Pénurie de relecteurs

Il peut arriver qu'aucun membre n'ait le temps ou les compétences pour relire un tutoriel donné. Le Staff ne trouve donc aucun relecteur.

Pour résoudre ce problème, il faut prendre conscience que le système de relecture par les pairs est une généralisation du système existant. Bien que sous-optimale, la solution « un seul relecteur, qui est membre du staff » correspond exactement à ce qui se fait aujourd'hui. Donc, si personne ne veut relire le tuto, un staff (seul) s'en chargera, comme cela se pratique aujourd'hui.

Dans cette situation, on perdra les avantages du nouveau système, mais on fonctionnera aussi bien qu'avec l'ancien.

Désaccord au sein du staff

Deux types de désaccord peuvent survenir : sur les relecteurs, et sur la décision finale.

Désaccord sur les relecteurs : une partie du staff veut que X relise tel tuto, tandis que l'autre partie s'y oppose. Dans ce cas, on tranche pour l'inclusion de X dans les relecteurs. Après tout, deux avis valent mieux qu'un, et ça ne peut pas faire de mal d'avoir davantage de commentaires sur un tuto. (Quitte à ignorer les commentaires de X s'ils s'avèrent impertinents).

Désaccord sur la décision finale : au vu des commentaires des relecteurs, une partie du Staff est pour la validation du tuto, l'autre partie est contre. Dans ce cas, il y a vote au sein du Staff. (Ce genre de désaccord est extrêmement rare ; dans tous les cas qui se sont présentés jusqu'à ce jour, un consensus a systématiquement émergé de la discussion).

Implémentation proposée

Première phase : expérimentation

Le site Zeste de Savoir permet, à l'heure actuelle, de pratiquer la relecture par les pairs « à la main ». En d'autres termes, on fait tout avec des MPs et le forum Staff. Cela nécessite une certaine coordination, donc chaque tuto aura un « responsable » au sein du Staff (sur la base du volontariat, comme le système de réservations actuel).

Le responsable d'un tuto s'occupera de chercher les relecteurs, de les contacter par MP, de leur fournir une copie du tuto, de récupérer les avis, puis faire suivre la décision finale à l'auteur. Le responsable d'un tuto crée un topic dans le forum Staff s'il a besoin de prendre l'avis des autres (notamment pour le choix des relecteurs et décision finale).

En outre, cette implémentation « à la main » permet de faire tourner les deux systèmes en parallèle. Ainsi, on peut expérimenter la relecture par les pairs sur un petit nombre de tutos, tout en continuant de valider les autres comme d'habitude. Cette expérimentation permettra de se rendre compte de la pertinence du projet, des problèmes qui peuvent survenir, et de définir le cahier des charges pour la phase suivante.

Deuxième phase : intégration au site

Si l'expérimentation est concluante, et que l'on souhaite généraliser le principe de relecture par les pairs à tous les tutos, une demande de fonctionnalité sera formulée auprès des développeurs. L'idée est d'automatiser le processus en ajoutant quelques boutons/formulaires à l'interface de validation :

• un bouton pour créer directement un sujet concernant un tuto sur le forum staff, pré-rempli avec un template ;
• un formulaire pour demande de relecture de tuto, dans lequel un staff saisit une liste de membres, et qui s'occupe d'envoyer un MP de demande de relecture à chaque membre indiqué ;
• une interface de relecture pour les membres ayant accepté de relire, qui leur permet d'accéder à la version hors-ligne d'un tuto, puis de rédiger des commentaires, qui seront directement postés sur le topic du tuto dans le forum staff ;
• ces trois éléments viennent s'ajouter à l'interface de validation actuelle, ils ne la remplacent pas.

Ainsi, il sera toujours possible au staff de valider directement un tuto sans le faire relire (utile en cas de modification mineure).

Arguments en faveur du système de relecture par les pairs

C'est facile à faire

Bien que le système paraisse lourd à mettre en place, je suis convaincu que nous pouvons le déployer sans trop de peine.

Il s'agit d'un système que l'on peut expérimenter dès à présent, sur un petit nombre de tutoriels. Par la suite, il pourra être automatisé avec un peu de développement. Dans tous les cas, ce système se rajoute au processus de validation actuel sans le remplacer : il ne fait que rajouter des possibilités au staff, sans le contraindre. De la même façon, il ne devrait pas nécessiter de grosses modifications sur le code existant, simplement l'ajout d'un ou deux nouveaux modules.

Ça soulage le staff

Ce système permet de déléguer aux membres la validation d'un tutoriel qu'il est incapable de valider, par manque de temps ou de compétences.

En outre, le membre du Staff ne porte plus seul le poids de la validation ; il dispose de plusieurs avis de membres pour s'éclairer, ce qui lui permet de formuler des commentaires plus précis et nuancés.

Enfin, ce système permet de repérer les membres prometteurs pour le poste de validateur. Un relecteur acceptant régulièrement de relire des tutos et fournissant des commentaires de qualité pourra ainsi être intégré au staff.

Ça fait participer la communauté

C'est un sujet de discussion récurrent, et à chaque débat sur le système de validation, des propositions en ce sens reviennent. La relecture par les pairs permet de faire participer la communauté, tout en évitant les solutions à base de vote populaire (qui ont leur lot d'inconvénients). Cela fournit aux membres un moyen simple de s'impliquer ponctuellement, sans forcément signer avec son sang pour rentrer dans le staff.

Conclusion

Merci d'avoir pris le temps de lire cette ZEP. Vos remarques et commentaires sont les bienvenus !

Je ne peux pas parler en connaissance de cause vu que je ne suis pas validateur mais si ça peut vous aider alors je suis complètement pour. D'autant plus que, comme tu l'as souligné, on ne perd rien, ou pas grand chose, à essayer.

Il ne m'a pas semblé avoir rencontré de problèmes dans ta spécification et je pense que le meilleur moyen, dans le cas présent, c'est directement de voir ce que ça donne. Sauf si, bien sûr, les validateurs s'y opposent.

Merci en tout cas !

Je ne peux pas parler en connaissance de cause vu que je ne suis pas validateur

En tant que membre, tu es auteur de tutos potentiel. Cette ZEP te concerne donc également, puisqu'elle décrit la procédure que ton tuto va subir avant d'être validé ou rejeté.

En outre, avec ce nouveau régime, tout membre pourrait être sollicité pour participer à la validation. Le refus est toujours possible, bien entendu, mais cela change le statut des membres vis-à-vis des tutos. Tu accepterais de relire et commenter (anonymement) un tuto de crypto, toi ?

J'ai effectivement rédigé cette ZEP du point de vue d'un validateur, mais le sentiment des membres est très important.

Il ne m'a pas semblé avoir rencontré de problèmes dans ta spécification

En vérité, il reste un point à éclaircir : comment choisir entre la relecture par les pairs et la validation « à l'ancienne ». Comme la ZEP le mentionne déjà, on ne va pas faire intervenir 3 relecteurs pour la correction d'une faute de frappe… De même, s'il est évident que le tuto doit être refusé (ou accepté), on peut gagner du temps et le faire directement. Nous avons donc besoin d'une politique (pas une règle stricte, mais au moins une guideline) qui détermine quand choisir quelle solution, en prenant en compte les cas les plus courants. C'est plutôt quelque chose à décider entre validos, mais c'est cool d'en débattre ici avec les membres.

Reste aussi la question des re-soumissions : le tuto a été refusé avec des demandes de modifications, les modifications ont été faites. Il faut donc valider cette nouvelle version. Choisit-on les mêmes relecteurs que pour la première version, ou bien de nouveaux relecteurs ? Chaque possibilité a des inconvénients : plus de travail pour les relecteurs VS moins de cohérence dans la validation d'un tuto.

Perso, je suis plutôt en faveur de la solution «on reprend les mêmes relecteurs pour les version successives d'un tuto», quitte à en trouver de nouveaux si les anciens abandonnent par manque de temps ou de motivation.

Je suis globalement pour, mais j'ai quelques questions et remarques.

• Qu'en est-il des articles ?
• Comment savoir quels membres s'y connaissent en quoi ? On a une idée générale pour la plupart des membres actifs, mais sans connaître les spécialités souvent.
• Y a-t-il un vrai problème avec la durée de validation actuellement ? Il me semblait que ça s'était amélioré.
• Cette idée diminuerait certes la charge de travail du staff, mais n'accèlererait très probablement pas la validation. Il suffit de voir le temps que ça prend dans la communauté scientifique, alors que c'est connu et accepté de tous qu'il faut parfois revoir l'article de quelqu'un d'autre.

Pour les re-soumissions, je suis en faveur de garder les mêmes relecteurs. Ils seront plus à même de voir si les problèmes soulevés ont été corrigés, et avoir trois relecteurs (et un staff en charge du tuto quand même) assure déja une pluralité des points de vue.

Bonjour GuilOooo, félicitation pour la rédaction qui est au poil (pour un loup, c'est le minimum attendu ).

Plus sérieusement, je trouve l'idée très pertinente et effectivement meilleure que le système actuel. Je ne sais pas précisément comment se passe le procédé de validation précisément à présent, mais je sais que 3 avis est un minimum qui est tout de même bon d'avoir. Je ne dis pas ne pas avoir confiance en le staff actuel, loin de là. Mais ça reste une petite équipe (entendre par là équipe restreinte) et submergée qui plus est. Donc agrandir le nombre d'avis me semble nécessaire.

La difficulté effectivement est de trouver à qui proposer ce poste de relecteur anonyme. Peut-être demandé une inscription aux membres intéressés en leur demandant de préciser leur(s) domaine(s) de prédilection ?

Tu parles également de garder les relecteurs d'une publication à l'autre, ça me semble en effet la meilleure solution, sinon on perd un temps incroyable…

De toute façon, c'est une méthode très bien expliquée et très pertinente à laquelle il me plairait bien de participer.

Je suis personnellement plus que favorable à son implémentation.

EDIT :

TL;DR : après réflexion, le but de cette ZEP est avant tout de permettre au staff de déléguer la validation aux membres, selon ses envies. Cela permet à un plus grand nombre de personnes de travailler sur la validation, sans forcément intégrer ces personnes dans le staff. Ainsi, des « experts » pourront nous aider ponctuellement sur des tutos très pointus, et nous pourrons déléguer davantage dans les périodes chargées. Ceci évite l'effet yoyo : beaucoup de tutos en attente → on recrute → les tutos sont traités → les nouvelles recrues n'ont plus rien à faire. Cela permettra en outre de mieux scaler lorsque le site grandira. FIN TL;DR

• Qu'en est-il des articles ?

Je n'ai volontairement pas parlé des articles, parce que je n'en sais rien. Le contenu d'un article peut être bien plus divers que celui d'un tuto ; ce peut être un message de service (« nouvelle version de ZdS »), la sortie d'un nouveau logiciel/technologie, ou un article « découverte ». Difficile d'établir une procédure de validation unifiée pour des choses aussi variées, je suis donc partisan de maintenir le système actuel aux articles pour le moment.

• Comment savoir quels membres s'y connaissent en quoi ? On a une idée générale pour la plupart des membres actifs, mais sans connaître les spécialités souvent.

Du temps du SdZ (ce qui semble se reproduire ici), le staff avait toujours sous le code quelques membres qui s'y connaissaient dans chaque domaine. On les repérait parcequ'ils étaient auteurs de bons tutos (je sais, ça crée une boucle sans fin), parce qu'ils postaient des messages pertinents sur le forum, et gloablement parce qu'on connaît nos membres.

C'est pour cela que l'aspect «confiance du staff» est également important. L'idée est de confier les relectures à des membres que l'on connaît, dont on sait qu'ils feront des retours de qualité. Typiquement, on a de nombreux « ex-staff » (de ZdS ou de OC) qui ont offert de « donner un coup de main » à la validation, sans pour autant reprendre le badge. La relecture par les pairs serait un moyen d'institutionnaliser cette pratique.

• Y a-t-il un vrai problème avec la durée de validation actuellement ? Il me semblait que ça s'était amélioré.

L'objectif n'est pas tant de diminuer les délais que de laisser au staff la possibilité de respirer. Nous n'avons actuellement pas envie d'avoir un « gros » staff, nous ne pouvons donc pas nous permettre d'avoir au moins 2 spécialistes de chaque domaine. L'idée est de déléguer la validation des tutos « délicats », sans laisser s'écouler des semaines sous prétexte que personne ne veut s'en occuper. (Je plaide coupable).

• Cette idée diminuerait certes la charge de travail du staff, mais n'accèlererait très probablement pas la validation. Il suffit de voir le temps que ça prend dans la communauté scientifique, alors que c'est connu et accepté de tous qu'il faut parfois revoir l'article de quelqu'un d'autre.

Tout à fait. Le but n'est pas de réduire les délais, mais bien de nécessiter moins de staff.

En outre, l'objectif n'est pas de reproduire trait pour trait le comportement de la communauté scientifique, mais simplement de s'en inspirer. Comme je l'ai mentionné, le staff garde la possibilité de valider/refuser des tutos sans relectures par les pairs, ce qui accélère le processus dans les cas évidents.

Enfin, la relecture par les pairs simplifie la validation pour les non-spécialites. Non que j'aie l'intention de laisser des gens complètement ignorants valider des tutos, mais avoir des avis d'experts de la communauté permettra de valider des tutos plus pointus avec plus de confiance.

D'une façon générale, ça permet à plus de gens de participer à la validation, sans devoir les passer staff et sans recourir à un vote populaire. On pourra être une centaine de personnes à s'impliquer dans la validation, sans que ce soit le bazar de gérer un staff de 100 personnes.

Pour les re-soumissions, je suis en faveur de garder les mêmes relecteurs. Ils seront plus à même de voir si les problèmes soulevés ont été corrigés, et avoir trois relecteurs (et un staff en charge du tuto quand même) assure déja une pluralité des points de vue.

Nous sommes d'accord.

@Poupou9779 : merci pour tes commentaires positifs, je relève juste ta question :

La difficulté effectivement est de trouver à qui proposer ce poste de relecteur anonyme. Peut-être demandé une inscription aux membres intéressés en leur demandant de préciser leur(s) domaine(s) de prédilection ?

Personnellement, je préfère que l'initiative vienne du staff. Par exemple, je suis fan de langages fonctionnels (OCaml, Haskell, Common Lisp etc.), je sais qui est fort dans ce domaine sur ZdS. Il y a peut-être des membres forts en Haskell que je ne connais pas encore, mais je finirai bien par les découvrir, et en attendant j'ai assez de contacts à qui m'adresser pour avoir un avis. C'est important : si je m'occupe de valider un tutoriel Haskell, par exemple, je vais préférer prendre l'avis de gens que je connais, en qui j'ai confiance. Non seulement parce que je sais que ces gens sont forts (pas juste parce que j'ai vu leurs réponses sur les forums, mais bien parce que je les connais), mais aussi parce que j'aime bien travailler avec eux.

Justification tout à fait convaincante, rien à redire.

Je vais encore laisser passer quelques jours pour récolter vos retours, puis je prévois de mettre à jour cette ZEP en version 2. Les changements prévus sont :

• éclaircir les motivations (pas une question de rythme, mais plutôt d'organisation) ;
• ajout d'un détail : on peut sélectionner un “noob” parmi les relecteurs, en plus des experts, pour avoir le point de vue de quelqu'un qui découvre ;
• détailler la sélection des relecteurs : insister sur le fait que le staff est discrétionnaire, et expliquer que celui-ci connaît assez de membres pour pouvoir faire la sélection ;
• préciser que les articles ne sont pas concernés (on fera peut-être une ZEP à part) ;
• préciser que les relecteurs vont relire les versions successives d'un tuto jusqu'à sa validation (sauf s'ils abandonnent en cours de route, au quel cas on en trouve de nouveaux… on ne peut forcer personne à rester) ;
• insister davantage sur le fait que le staff peut également faire de la validation à l'ancienne, et qu'il le fera pour les mises à jour mineures et les tutos très bons et très mauvais (décision évidente).

EDIT 28/12/2014 : suite à la discussion ci-après :

• changer « anonyme » par « non-anonyme » (et le justifier par le fait qu'au début, ce sera une simple expérience entre gens de confiance, et qu'ensuite, on pourra changer le système en fonction des besoins).

Le staff, à la lumière des commentaires des relecteurs, prend la décision de validation ou refus. Dans tous les cas, il fait suivre les commentaires des relecteurs à l'auteur, de façon anonyme.

C'est vraiment utile ça ? L'aide en bêtazone montre quand même que les membres savent accepter la critique des autres. Je pense que savoir qui est l'autre est important, surtout pour ouvrir un dialogue (comme dans 99% des cas).

Pour la partie "Désaccord au sein du staff", ça ne me semble pas vraiment utile non plus. Je veux dire, il y a un valido dédié et deux/trois membres compétents donnant leur avis. Je ne pense pas que du coté du staff, on va se braquer juste pour la déco. Si quelqu'un du staff est pas d'accord, il argumentera et il suffira de faire suivre. Alourdir le système pour le cas où n'est AMHA pas utile.

Le peer review peut être utile pour les articles mais pas nécessaire au stade actuel.

Pour toute la partie « désaccord au sein du staff », je blinde le système à mort pour éviter que l'on soit bloqués. Évidemment, je croise tout ce que j'ai de doigts pour qu'on continue de fonctionner avec une si bonne ambiance, et que l'on arrive toujours à résoudre les désaccords au travers du dialogue. Ça a bien marché jusqu'ici, je pense donc que ces procédures de départage ne serviront jamais… Mais je les ai incluses au cas où.

Concernant l'anonymat, tu soulèves un point intéressant. J'admets ne pas avoir d'opinion à ce sujet ; pour le coup, j'ai repris le système scientifique sans me poser la question.

Je dirais que l'anonymat permet aux gens de se lancer dans une relecture sans avoir besoin de discuter avec l'auteur, ce qui leur prendra moins de temps que s'ils doivent échanger par MP. Ainsi, on aura potentiellement plus de gens motivés pour relire.

De l'autre côté, on perd effectivement toute la phase de dialogue, mais est-elle vraiment nécessaire ? Ici, le tuto est supposé être terminé, et on cherche à aboutir à une décision — oui ou non. Je ne suis pas sûr qu'il y ait besoin d'un dialogue à ce stade ; si le tuto est refusé, l'auteur peut toujours revenir sur la beta-zone et dire « on m'a refusé le tuto pour les raisons FOO, je compte le modifier de la façon BAR, qu'en pensez-vous ? ».

De l'autre côté, on perd effectivement toute la phase de dialogue, mais est-elle vraiment nécessaire ? Ici, le tuto est supposé être terminé, et on cherche à aboutir à une décision — oui ou non. Je ne suis pas sûr qu'il y ait besoin d'un dialogue à ce stade ; si le tuto est refusé, l'auteur peut toujours revenir sur la beta-zone et dire « on m'a refusé le tuto pour les raisons FOO, je compte le modifier de la façon BAR, qu'en pensez-vous ? ».

Sauf qu'avec le système présenté, c'est le staffeux qui va motiver la décision selon les arguments des relecteurs. Le bémol, c'est qu'il y a toujours des remarques même si le tuto est présumé terminé car tout n'est pas signalé en bêta donc le dialogue subsiste. De plus, par honnêteté, si l'auteur repasse son tuto en bêta que j'ai été relecteur, j'aurais tendance à poster pour détailler mes propos, pour le conseiller. Ma méthodologie sera donc différente (juger un tuto/conseiller pour l'améliorer) alors autant permettre à l'auteur et aux autres relecteurs de savoir qui participe à la validation.

Au pire, on peut demander au relecteur s'il souhaite s'impliquer dans le tutoriel ou tout simplement vous donner son aval ou son refus.

En outre, en indiquant aux relecteurs qui sont les autres relecteurs, ne risque-t-on pas d'avoir des opinions biaisées ? Pas de machination non, mais des trucs du genre "Eh, t'as mis quoi toi ?" ?

Non, pas vraiment. Les personnes sélectionnées seront consciencieuses.

D'accord.

Sinon, on peut essayer au début en mentionnant les noms et si jamais ça ne convient pas on revient au système initial.

Excellente idée de ZEP, j'approuve des deux mains. Bon, j'ai fait de la recherche, ça doit jouer dans mon avis sur la question.

Pour Arius : le principe de l'anonymat sert à parer à toute éventualité. Effectivement, pour l'instant, dans notre communauté assez réduite, tout se passe globalement dans une ambiance bon enfant. Je dis globalement, cf. les commentaires de katana dans la bêta sur le concept de l'orienté objet. Sauf que rien ne dit que ça dure. Le but de ne pas dire à Toto que c'est Tutu qui lui a fait tel commentaire acerbe sur son tuto, c'est pour que le jour où Toto doit relire un article de Tutu (ça finira par arriver, les spécialistes d'un même domaine ne sont pas nombreux), il ne soit pas tenté de se venger, ou tout simplement qu'il ne soit pas dans un état d'esprit négatif vis-à-vis de Tutu, ce qui influencerait sa relecture.

C'est juste pour ça : ça met de l'huile dans les rouages. Et à mon sens, c'est important.

• ajout d'un détail : on peut sélectionner un “noob” parmi les relecteurs, en plus des experts, pour avoir le point de vue de quelqu'un qui découvre ;

En lisant le début de la ZEP, je comptais en parler et je vois que tu l'as fait avant moi. En effet, faire relire aussi par quelqu'un qui n'y connaît presque rien est important pour évaluer la qualité pédagogique du tuto. Pour donner un exemple, la méconnaissance de Vayel vis-à-vis de la crypto m'a été particulièrement utile lors de la rédaction de notre tuto commun sur RSA pour justement mettre en lumière tous les passages où je restais trop implicite.

Le choix du "noob", il se fera comment ?

Hum, c'est pas faux mais je persiste à penser qu'il faut mettre en avant le dialogue d'une manière générale parce que de toute façon, les membres ayant un mauvais tempérament ont peu de chance d'être choisis. Il s'agit de sélectionner des personnes compétentes et pédagogues donc… (faudra établir des critères de toute façon)

Le choix du "noob", il se fera comment ?

Comme les autres : je choisis une personnne dont je sais qu'elle n'y connaît rien en Haskell (pour reprendre mon exemple), mais que je connais pour son sérieux.

de toute façon, les membres ayant un mauvais tempérament ont peu de chance d'être choisis.

Tout à fait. L'anonymat servirait plutôt à protéger les relecteurs des auteurs un peu virulents (d'ici quelques mois, on aura bien un tuto soumis par un jeune qui n'a pas encore l'habitude de recevoir des critiques. ). Autrement, rien n'empêche les relecteurs d'oblitérer leur anonymat sur le forum bêta-zone s'ils en ont envie.

Autrement, j'aimerais mettre une chose au point : le staff motive la décisison finale, mais l'auteur reçoit les commentaires des relecteurs en plus de la décision (motivée) du staff. Il peut ainsi les lire, les prendre en compte, et s'améliorer. Je ne suis pas certain que ce point soit bien passé dans la ZEP, mais les commentaires rédigés par les relecteurs seront lus par l'auteur, tels quels. On enlève juste les pseudos.

Au pire, pour le dialogue, l'auteur, s'il souhaite plus de détails sur les commentaires et/ou les raisons du refus, peut contacter le membre du staff ayant rendant le verdict. Suite à cela, le validateur indiquera aux relecteurs que l'auteur souhaite plus d'informations et les relecteurs pourront décider de le contacter ou non.

La situation un peu gênante serait :

• Auteur : eh staff, peut-on détailler ce commentaire ?
• Validateur : j'indique aux relecteurs que tu souhaites en savoir plus.
• Un relecteur : je refuse de répondre.
• Auteur pleure (et rage).

Mais comme vous sélectionnerez des relecteurs responsables, ce cas de figure risquera peu de se produire.

L'idée est que l'anonymat est un processus plus général que le travail à identités révélées. Si on fournit les commentaires anonymement, on peut toujours lever cet anonymat au besoin. À l'opposé, si l'on travaille à identités révélées, plus moyen de revenir en arrière…

Effectivement, cela introduit une certaine lourdeur dans le processus. On pourra la mitiger avec un peu de développement, par exemple en faisant un MP spécial entre l'auteur et les relecteurs, de telle façon que les pseudos des relecteurs n'apparaissent pas dans ce MP. Mais j'aimais bien l'idée que le processus de validation par les pairs soit expérimentale en l'état actuel du site.

Je propose d'utiliser un système de relecture non-anonyme pour l'expérimentation. Étant donné qu'il s'agit d'une expérience, nous allons l'appliquer seulement aux auteurs en qui nous avons confiance. Ainsi, tout devrait bien se passer. À l'issue de cette expérience, nous pourrons déterminer avec un peu plus de recul si l'anonymat est nécessaire ou non, et si oui, sous quelle forme l'implémenter. Nous irons alors voir les dévs pour leur demander d'implémenter les fonctionnalités dont nous avons besoin (qui feront l'objet d'une ZEP séparée).

• Auteur : eh staff, peut-on détailler ce commentaire ?
• Validateur : j'indique aux relecteurs que tu souhaites en savoir plus.
• Un relecteur : je refuse de répondre.
• Auteur pleure (et rage).

Justement, la partie où le relecteur refuse de répondre n'est pas censée arriver vu que les relecteurs sont choisis pour leur capacité à donner des critères de critiques pertinents et pour leur capacité à les développer. Donc un relecteur qui déciderait de ne pas répondre ne serait d'office pas choisi.

Et de manière plus générale, si un(e) commentaire/critique refuse d'être argumenté(e), c'est qu'il/elle n'a pas à être pris en compte.