ZEP-41 : Workflow éditorial

L'objectif de cette ZEP est de formaliser le workflow éditorial, et notamment de mettre en place le rôle de correcteur introduit dans ce sujet.

État de la situation

Entre le moment où un auteur a une idée de contenu et celui où l’on peut considérer le travail éditorial comme abouti, un certain nombre d’étapes doivent être franchies.

• Rédaction du contenu.
• Acceptation du contenu quant au fond, ce qui regroupe :
  • qualité de la pédagogie ;
  • organisation logique du propos ;
  • correction factuelle des informations ;
  • nombre et nature adéquats des illustrations (images, codes d’exemple, etc.).
• Acceptation du contenu quant à la forme, ce qui regroupe :
  • clarté des formulations ;
  • correction linguistique des propos ;
  • justesse orthographique de l’écrit ;
  • correction de la typographie ;
  • mise en forme optimale du contenu.
• Choix d’une date de publication du contenu.
• Mise à disposition de formats alternatifs du contenu (PDF, ePub, etc.).
• Publicité de l’existence du contenu.
• Lecture du contenu par son public.
• Retours du public sur le contenu.

L’ordre donné ci-dessus correspond globalement à ce qui est considéré, d’après les différentes demandes d’avis faites jusqu’à présent, comme l’ordre optimal dans lequel les étapes doivent être franchies. À noter qu’il est tout à fait possible de procéder à des retours en arrière à différentes étapes : un format alternatif de publication peut justifier une nouvelle mise en forme ; un contenu publié depuis longtemps peut être remis sous les feux de la rampe ; les retours sur le contenu peuvent amener à reprendre la rédaction du contenu de manière plus ou moins importante.

Cette chaîne éditoriale fait intervenir un certain nombre d’acteurs, dans l’état actuel des choses sur ZdS, chaque personne pouvant être partie intégrante de plusieurs de ces acteurs.

• Le ou les auteurs.
• Le ou les illustrateurs.
• L’éditeur ZdS, représenté par le CA de l’association, et qui confie une partie de ses missions à d’autres acteurs :
  • les validateurs ;
  • l’équipe de com.
• Les lecteurs.

Dans l’état actuel des choses, voici comment interviennent les différents acteurs.

• Les auteurs et illustrateurs sont seuls intervenants de la partie rédaction.
• Les deux phases d’acceptation font intervenir à la fois les lecteurs, par le biais de la bêta, lorsqu’elle est mise en place par les auteurs, et les validateurs, lors de la procédure de validation officielle.
• La date de publication des contenus semble être prise en charge par les validateurs de manière collégiale.
• La mise à disposition de formats alternatifs est actuellement à l’état d’ébauche.
• La publicité des contenus récents est gérée automatiquement sur la page d’accueil, et manuellement par l’équipe de com, par le biais de messages sur les réseaux sociaux. Cette publicité peut être réitérée par la suite par de nouveaux messages sur les réseaux sociaux ou par le système des unes. Les lecteurs peuvent également contribuer à cet effort, au moyen des boutons de partage.
• La lecture se fait naturellement par les lecteurs, et semble être l’aspect le plus simple à traiter.
• Les retours après publication sont aussi le fait des lecteurs, qui peuvent commenter les contenus, faire des remarques par le biais du bouton « Signaler une faute » ou encore contacter directement les auteurs par MP.

Objectifs et solutions

L’objectif d’un bon workflow est de répartir le rôle de chacun des acteurs de manière à assurer la progression la plus efficace possible des contenus le long de la chaîne éditoriale, en évitant notamment que l’on se « marche sur les pieds ». L’objectif d’une bonne plate-forme d’édition, c’est d’offrir à chacun des acteurs les moyens de jouer son rôle dans les meilleures conditions possibles.

Un certain nombre de ZEP et discussions ont déjà abordé la plupart des étapes de ce workflow : la ZEP-05 et ce sujet sur les formats alternatifs, ainsi que la ZEP-28 dans une certaine mesure, ZEP-22 sur les retours, ZEP-03b sur la phase de rédaction, etc. La question ici serait plutôt centrée sur les deux phases d’acceptation.

En effet, le fait que les deux étapes ne soient pas clairement séparées, et que lecteurs et validateurs marchent sur les mêmes plate-bandes, pose un certain nombre de problèmes, ainsi qu’en témoigne le nombre de corrections sur la forme apportées lors de l’étape des retours de la part du lectorat, censément la dernière.

• Il y a une tendance manifeste des relecteurs en bêta à donner pêle-mêle des retours concernant le fond et concernant la forme, et ceci malgré le fait que l’on ait abondamment répété qu’il est inutile et contre-productif de corriger formellement un texte qui va potentiellement disparaître.
• Les validateurs doivent assumer la triple fonction d’expert reviewer sur le fond, de correcteur ortho-typographique et d’organisateur d’un ordre du jour éditorial, ce qui fait beaucoup de compétences à réunir dans la même personne. L’expérience montre que c’est généralement le deuxième point qui est délaissé.
• La bêta a un statut bâtard. Elle reste le meilleur moyen de réunir un grand nombre d’avis, tant de personnes compétentes que de lecteurs du public cible. Mais en fin de compte, le validateur garde une position prépondérante, et peut même être amené, dans le cadre de la ZEP-20, à constituer son propre panel d’experts pour effectuer une nouvelle revue par des pairs, rendant ainsi quelque peu futile le travail des relecteurs en bêta. En outre, un certain nombre d’auteurs ont signalé qu’un contenu qui ne reçoit aucun retour en bêta peut être décourageant pour ses auteurs.
• Lorsque les relecteurs se restreignent sur la correction formelle, celle-ci passe généralement à la trappe, faute que l’auteur signale le moment où il estime qu’elle doive intervenir, le fond étant définitif. Et à vrai dire, comme le validateur peut être amené à faire modifier encore le fond indépendamment de ce qui a pu être dit en bêta, rien ne garantit que la correction alors apportée puisse être définitive.

Dans ces conditions, il apparaît nécessaire de démêler l’imbroglio que constitue cette phase d’acceptation d’un contenu. Et à mon sens, cela passe par deux actions (et la mise en place de quelques outils pour en faciliter la mise en œuvre).

Étape 1 : correcteurs agréés

La première de ces actions serait d’introduire un nouvel acteur dans la chaîne éditoriale, en la personne de correcteurs agréés par l’éditeur. Ceux-ci prendraient en charge la phase d’acceptation du contenu quant à la forme (cf. plus haut), avec éventuellement une aide ponctuelle des relecteurs de bêta pour la clarté des formulations. Cette seconde phase de l’acceptation d’un contenu serait par conséquent retirée aux validateurs et aux relecteurs, la bêta ne portant plus alors que sur le fond.

Pourquoi avoir des correcteurs spécifiquement identifiés ? Précisément pour décharger les validateurs de ce travail, qu’ils trouvent généralement pénible, et pour lequel nombre d’entre eux, soit ne sont pas très à l’aise avec les règles orthographiques et typographiques, soit sont sensiblement plus lents que ne le serait un correcteur. Ainsi, les validateurs pourraient être recrutés pour leur maîtrise d’un domaine, sans se soucier outre mesure de leur maîtrise de l’orthographe et de la typographie. Et parce qu’en reportant la phase de correction formelle après que le contenu a été entièrement validé sur le fond, on garantit que chaque contenu soit corrigé au moins une fois, et qu’il ne soit pas corrigé inutilement car trop tôt.

Pourquoi ceux-ci doivent-ils avoir un bandeau vert ? En premier lieu et avant tout pour leur donner une légitimité : de même que les paroles d’un validateur sur le fond ont plus de poids que celles d’un simple relecteur, un « validateur de la forme » doit avoir une certaine autorité morale. En deuxième lieu, parce que cela permet en contrepartie à l’éditeur d’imposer un code déontologique à ses correcteurs agréés (cf. plus bas). En troisième lieu, la relecture formelle étant un travail très peu gratifiant, il est impératif que celle-ci puisse s’opérer dans de bonnes conditions, afin de ne pas entamer la motivation des correcteurs par des désagréments bassement techniques (j’ai malheureusement constaté une certaine réticence de la part de nombreux auteurs à ce que les correcteurs puissent travailler correctement, sans aucun doute pour des motifs peu avouables d’ego…).

Quelle déontologie pour les correcteurs ? Le système d’historique permet d’avoir un suivi précis de toute modification que ferait un correcteur. La déontologie pourrait donc se limiter à l’essentiel, à savoir qu’est-ce qu’un correcteur peut modifier et comment ? A priori, c’est assez simple :

• pour les formulations peu claires et l’organisation des illustrations, le correcteur peut suggérer des modifications, que l’auteur est libre d’accepter ou non ;
• pour les formulations linguistiquement incorrectes, le correcteur peut suggérer une formulation plus correcte, et l’auteur peut soit l’accepter, soit en employer une autre, mais pas refuser la correction en bloc (sauf motif légitime, bien sûr) ;
• pour le reste, le correcteur est autorisé à modifier unilatéralement le texte, l’auteur restant bien sûr libre de contester une correction, de même qu’il peut contester une demande du validateur sur le fond.

Quels outils pour les correcteurs ? Avoir les permissions nécessaires pour modifier le texte directement est indispensable. Une charte typographique minimale est en cours de rédaction, devra être validée par ZdS en tant qu’éditeur, et permettra aux correcteurs d’avoir quelque chose à opposer aux éventuels contestataires sur la question litigieuse de la typographie. Une évolution du markdown prenant en charge une partie de la typographie française de manière automatique permettrait de considérablement simplifier ladite charte typographique.

Réponse à quelques craintes soulevées. Comment recruter des correcteurs compétents ? De la même manière que l’on recrute des validateurs compétents. Comment s’assurer de les conserver à long terme ? En leur donnant les outils nécessaires pour travailler correctement, et en évitant de contester à tout bout de champ leur action (typo-grammar nazi, plus qu’une passion, c’est un art de vivre). Que faire si aucun correcteur ne se présente ? Ce qu’on fait quand aucun validateur ne se présente. Ça va encore allonger la validation !? Pas nécessairement : les validateurs pourront se concentrer sur le seul fond, sans chercher à traquer les fautes, et laisser ce travail-là à des gens qui en ont l’habitude, et travaillent donc plus vite ; s’adresser à Eskimon ou victorlevasseur pour un témoignage de première main sur le temps que prend une correction complète.

Étape 2 : bêtas repensées

La deuxième action à mettre en place serait un recentrage de la bêta comme outil de pré-validation du contenu. L’existence de correcteurs agréés supprimerait ainsi le besoin de signaler les fautes lors de la bêta : on ne pourrait pas totalement empêcher les relecteurs de signaler celles qu’ils voient, mais à tout le moins, ceux qui se sentent habituellement le devoir de le faire pourraient se concentrer sur le fond.

La première chose à mettre en place serait un outil : l’amélioration déjà proposée du bouton « Signaler une erreur », qui permettrait de commenter le contenu depuis le contenu lui-même, plutôt que de faire des allers et retours entre le contenu et le moyen de communication avec l’auteur (forum-bêta ou MP). L’idée a été approuvée aussi bien par des relecteurs que par des validateurs.

Viendrait ensuite une évolution des pratiques : lorsque l’auteur a pris la peine de mettre son contenu en bêta, et a fortiori quand celle-ci a généré une participation importante des relecteurs, il serait de bon ton que les commentaires du validateur soient également postés sur la bêta, de manière à pouvoir être commentés si besoin par les autres relecteurs : cela s’intégrerait parfaitement dans la dynamique de la ZEP-20. En outre, cela valoriserait le travail des relecteurs, en plaçant le validateur dans une position de primus inter pares.

Le sujet de bêta contiendrait ainsi les remarques des relecteurs et des validateurs. On peut étendre le concept en y intégrant les remarques intervenant après la publication. En somme, ce sujet rassemblerait toutes (la grande majorité des) les remarques concernant le contenu, et ne pourrait donc pas être fermé une fois la publication franchie.

Afin de limiter les interférences entre validation et bêta, étant entendu qu’il est appréciable qu’un contenu reste accessible en bêta jusqu’à l’heure de sa publication, on pourrait également mettre en place un système qui fait que le sujet de la bêta est gelé à partir du moment où un validateur réserve un contenu, mais la bêta reste accessible en lecture pendant ce temps-là. Le sujet serait rouvert lorsque le validateur abandonne le contenu ou poste son commentaire dans le sujet de bêta (ce qui pourrait se faire automatiquement via l’outil mentionné deux paragraphes plus haut).

Dans l'optique de suivre l'évolution d'un contenu, des messages automatiques seraient ajoutés. Notamment, un contenu envoyé en validation, et à fortiori réservé, ne devrait pas être prioritaire pour recevoir des remarques. Afin de suivre facilement toutes ces évolutions, un historique pourrait être tenu dans le premier message et des tags ajoutés au sujet selon l'étape courante.

Concluons

Il reste quelques points particuliers à traiter, notamment les messages automatiques et les tags, mais je crée la ZEP tout de suite afin que vous puissiez faire vos retours sur le principe (déjà bien ébauché).

Certains auront peut-être discerné la patte du Carnufex dans ce texte. Il m’a effectivement largement aidé dans la rédaction de cette ZEP et je le remercie grandement pour cet excellent travail.

Si vous partez sur cette idée, il faudra penser à notifier de l'existence des rédacteurs en chef (IMO un nom plus cool serait plus approprié d'ailleurs pour éviter de paraitre trop stricte, mais j'ai pas d'idées). Ça peut se faire via un message au moment de la création du contenu qui liste les rédacs-chef du moment et leurs domaines d'application ou alors via un message de Clem à l'inscription/la création d'un contenu.

@Victor

Tu dis qu'il ne faut pas trop formaliser et tu définies juste après plusieurs rôles C'est peut être contradictoire.

HS : pour ceux qui ne me connaissent pas, une précision : j'ai été responsable de la rubrique C++ sur Developpez.com pendant 1 an et demi (environ), donc j'ai remplit ce rôle de "rédacteur en chef". L'effet "avoir un rédacteur en chef" a un impact très important sur la motivation de l'"équipe de rédaction" et sur les publications.

Le rôle de "rédacteur en chef" est effectivement quelque chose de pas facile (j'aurais dit "super chiant"). De la même façon qu'il faut motiver les auteurs, il faut aussi garder la motivation du "rédacteur en chef". Pour cela, je pense qu'il faut lui faire un minimum confiance pour organiser son travail (ne pas avoir de rôles formalisés), lui laisser de la liberté (il ne doit pas être un "yes-man" ou un simple exécutant), l'encourager et le féliciter (se focaliser sur ce qu'il a fait de bien, pas ce qu'il aurait pu ou du faire), etc.

Une proposition : faire un appel de candidature pour le rôle de "rédacteur en chef". Chaque postulant propose son propre projet, la communauté/l'association vote et élit le rédacteur en chef pour 1 an (renouvelable). Les projets peuvent être "avoir plus de news", "avoir plus d'exos", "avoir plus de traductions", "avoir plus de parcours débutants" (coucou Stranger…), etc. Peu importe, il faut que ce soit une vision personnelle que le "rédacteur en chef" défende. Il faut qu'il connaisse bien ZdS, qu'il ait un bon relationnel, qu'il soit moteur. Il devra travailler en collaboration avec les devs (pour orienter, pas diriger) et les validateurs (qu'il devra manager), l'association (avoir un planning, présenter ses résultats - encore une fois, pas pour juger). Il faudra lui fournir le support technique pour être efficace (pouvoir donner des rôles, pouvoir demander des fonctionnalités à implémenter en priorité), etc.

A vous de voir comment vous voulez gérer la chose. Mais cela devra être basé sur la confiance. A mon avis, la seule formalisation qu'il faut faire, c'est le processus de nomination, les obligations de compte rendu (tout projet sérieux doit avoir des évaluations intermédiaires et finales) et une éventuelle destitution. Pas sur le contenu ou la méthode de travail.

T'as oublié les supers développeurs !

Tu dis qu'il ne faut pas trop formaliser et tu définies juste après plusieurs rôles

Je pense qu'il faut plusieurs rôles. Et je pense que ces rôles ne doivent pas être trop formalisés. Personne n'a envie d'avoir un règlement par rôle, plus un cahier des charges par rôle, plus…

A mon avis, la seule formalisation qu'il faut faire, c'est le processus de nomination, les obligations de compte rendu (tout projet sérieux doit avoir des évaluations intermédiaires et finales) et une éventuelle destitution. Pas sur le contenu ou la méthode de travail.

Exactement.

Je crois aussi qu'il faut plusieurs rôles. Par contre, je crois qu'il faut laisser au "rédacteur en chef" (ce que tu appelles "directeur de publication") la liberté de définir les rôles et constituer son équipe.

Et c'est pour cela que je parle de confiance : si on lui dit dès le départ "tu n'arriveras pas à gérer tout seul telle ou telle partie, donc on te limite tes attributions et on désigne d'autre rédacteur en chef", où est la confiance ?

Il n'a pas besoin d'avoir des compétences techniques dans tous les domaines qu'il encadre. C'est un rôle de management et d'animation. Les qualités personnelles sont plus importantes (être moteur). Et encore une fois : confiance. En particulier pour monter son équipe et s'entourer des personnes qui le compléteront sur les aspects techniques.

@gbdivers : c'est qu'une question de terminologie. Mon directeur de publication est ton rédacteur en chef, et mes rédacteurs en chefs sont l'équipe de ton rédacteur en chef. Dans le fond, on dit la même chose toi et moi.

Oui, on parle de la même chose. Je disais juste qu'il faut que ces rôles soient définis par le "rédacteur en chef", pas par nous.

Merci Vayel, très intéressant.

Et Dominus.

Merci pour vos messages qui offrent des pistes de réflexion pour rendre plus efficaces les auteurs. Mais quid des relecteurs (non validateurs) ? Actuellement, ils sont un peu livrés à eux-mêmes et travaillent globalement à l'instinct (globalement, hein). Certes, le guide du contributeur leur fournira un cadre de travail, mais il me semble intéressant, comme pour les auteurs, d'en avoir un interactif. Notamment, pensez-vous qu'il puisse être intéressant de faire participer les validateurs (des relecteurs compétents) à la phase de bêta ?

Par exemple, pour le tutoriel « Notions avancées de Python », nohar l'a relu et commenté et suivi les retours des autres relecteurs, lesquels ont pu bénéficier de son expérience de validateur. J'imagine qu'après ça, la phase de validation a été courte.

L'idée de directeurs de publication et de rédacteurs en chef est intéressante. Et il est tout à fait possible de la tester sans aucun développement, pour voir les résultats, un peu à la manière de la ZEP de Coyote.

Du coup, qu'est-ce qu'il faudrait pour pouvoir faire un test de (par example) 6 mois ? Des volontaires bien sûr. Affiner leur rôle pourrait être fait pendant le test. Est-ce qu'il faudrait que l'association approuve le changement d'oganisation ?

J'approuve ce qui est dit au-dessus jusqu'au 1^er message. On pourrait effectivement mettre en place cette ZEP par petit bout, et tester au fur et à mesure.

Concernant le rédac. chef, si j'y suis favorable, j'ai du mal à voir ce qu'il pourrait faire précisément. Si c'est proposer et relire des articles, tutos, ateliers, etc, c'est déjà possible actuellement. Chaque membre peut proposer une initiative, qui est plus ou moins couronnée de succès, relire les contenus d'autrui, proposer des articles à écrire, seul ou en groupe. Dans ce gloubi-boulga, qui marche, l'air de rien, quel serait le rôle du rédac. chef, et ne risque-t-il pas de limiter les initiatives (inconsciemment, si quelqu'un est responsable de l'animation, je vais avoir moins tendance à aller marcher sur ses plates-bandes) ?

Comme je le vois, ils ne seraient pas en charge de l'animation, mais auraient un rôle de coordination et de suivi.

Ils pourraient par exemple s'occuper de recensement comme celui-ci ou encore ici. Ils connaîtraient la majorité des membres et leurs points forts, et pourraient suggérer du travail collaboratif quand ce serait adapté. Ils pourraient, en privé, se renseigner régulièrement sur l'avancement d'articles et de tutos, éventuellement en suggérant quelques idées, pour essayer d'éviter une perte de motivation et la perte d'un contenu, parfois déjà avancé. Ce genre de choses, qui, je pense, ne limiteraient pas les initiatives personnelles.

De manière général, je suis assez d'accord avec le point de vue de gbdivers. Avec l'exception que je ne suis pas convaincu qu'ils devraient fixer un "axe prioritaire d'écriture", ou "projet", qui me semble être une contrainte supplémentaire sur les auteurs.

@Gabbro: quelqu'un de moteur dynamise les autres, il ne les limite pas dans leurs initiatives.

@Rockaround: je crois que le point principal, c'est la confiance (et la liberté) accordée au "rédac-chef". Avoir un projet ou un axe prioritaire est généralement plus motivant que de travailler sans but précis. Mais cela doit rester (à mon avis) la liberté du "rédac-chef" de proposer ou non un tel projet.

Ce serait dommage que cette ZEP soit abandonnée, elle peut apporter pas mal de points intéressants. J'aimerais notamment revenir sur 2 choses.

Tout d'abord, l'idée d'un rédacteur en chef me plaît bien. Je sais que certaines personnes le font déjà, en contactant les auteurs pour les motiver/accompagner au long de leur rédaction. J'aime notamment la proposition de gbdivers :

Une proposition : faire un appel de candidature pour le rôle de "rédacteur en chef". Chaque postulant propose son propre projet, la communauté/l'association vote et élit le rédacteur en chef pour 1 an (renouvelable). Les projets peuvent être "avoir plus de news", "avoir plus d'exos", "avoir plus de traductions", "avoir plus de parcours débutants" (coucou Stranger…), etc. Peu importe, il faut que ce soit une vision personnelle que le "rédacteur en chef" défende. Il faut qu'il connaisse bien ZdS, qu'il ait un bon relationnel, qu'il soit moteur. Il devra travailler en collaboration avec les devs (pour orienter, pas diriger) et les validateurs (qu'il devra manager), l'association (avoir un planning, présenter ses résultats - encore une fois, pas pour juger). Il faudra lui fournir le support technique pour être efficace (pouvoir donner des rôles, pouvoir demander des fonctionnalités à implémenter en priorité), etc.

Ce rédacteur en chef pourrait booster la rédaction. Bien sûr, avant d'attribuer un tel rôle, il faudra définir pas mal de choses, mais je pense qu'il pourrait être intéressant de creuser la chose.

Ensuite, pour revenir un peu plus au sujet de la ZEP, les correcteurs. Récemment, Dominus Carnufex m'a gentiment corrigé un des mes tutoriels. Pour que ce soit plus facile, je l'ai ajouté en auteur, le temps qu'il puisse effectuer ces corrections. C'est également moi qui ai fais la démarche pour qu'il jette un œil à mon contenu. Tout le monde ne fera pas ça, ce n'est clairement pas l'idéal.

Encore une fois, je pense qu'il serait intéressant d'avoir une réflexion quand au à la mise en place de ces correcteurs, leur apport n'en serait que bénéfique. Notamment :

• quand doivent-ils intervenir ?

• comment apportent-ils leur modifications ?

• les auteurs peuvent-ils refuser les modifications apportées par les correcteurs ?

Il y a déjà la page d'aide aux auteurs, la ZEP-08 qui se met en marche (mais qui risque de ne pas arriver avant longtemps), mais je pense qu'il faut donner un cadre à ces correcteurs.

Dominus Carnufex m'a également aidé à corriger les fautes d'un de mes tuto. Ca m'a bien arrangé (j'ai souvent la flemme de me relire ), tout a été assez simple, je l'ai ajouté comme auteur et quelques heures plus tard il était prêt à aller en validation. Ce système va beaucoup plus vite que la correction en bêta, où chacun propose une où deux petite correction par-ci, par-là et où il faut retourner dans le tuto pour éditer le mot qui va pas.

Donc, cette ZEP est cool !

Pour répondre aux questions d'Emeric, je dirait qu'ils faut qu'ils interviennent quand le fond est stable, tout simplement. Ils peuvent éditer le tuto comme si ils en étaient les auteurs. Les auteurs doivent pouvoir refuser des corrections, même si elles sont justes. C'est leur tutoriel, ils en font ce qu'il veulent. De toute façon, s'ils laissent des fautes, ça passera pas en validation. Ils doivent plus pouvoir refuser dans le cas où le correcteur change le sens en remplaçant un mot par un autre (histoire d'éviter des répétitions par exemple).

Avoir un directeur de la publication et plusieurs rédacteurs en chef, par catégorie, par format, etc. je vous le donne en mille : ça ne marchera pas sur le long terme. Vous essayez de calquer le fonctionnement d'un site comme Developpez.com à ZdS sans tenir compte de certains éléments :

• Nous essayons d'avoir la hiérarchie la plus plate possible, on aime pas du tout l'idée d'une hiérarchisation du staff
• En soi, ça n'aura pas d'impact sur la vitesse de validation qui est soumise à la contrainte temps du validateur ayant pris le contenu en charge (et il m'est d'avis que l'on va avoir besoin de nouveaux renforts)
• Ce serait trop lourd à gérer en interne et la hiérarchisation ouvre la voie à des conflits, on ne peut pas non plus avoir des personnes compétentes partout puisque nos recrutés potentiels proviennent de notre base de membres.

D'autre part, la discussion a dérivée… Avoir un workflow où dans un premier temps l'auteur échangerait avec un membre-correcteur, dans un rapport bilatéral est une chose (je note toutefois les pépins niveau délai avec les zCos), commencer à hiérarchiser en est une autre (et ce ne serait ni bénéfique, ni fonctionnel). Par contre,

• il faudrait effectivement donner les clés pour permettre au membre désireux d'écrire de pouvoir le faire (c'est le but du guide) et il faudrait que le staff joue aussi le rôle d'incitant.
• le fonctionnement de la bêta doit clairement être revu. Elle est délaissée par les membres, une poignée de chevaliers forts et honorables (cc vayel et les autres) font le boulot mais ce n'est clairement pas suffisant et à long terme, ils finiront par céder. Si l'on veut privilégier le rapport bilatéral (auteur- correcteur puis auteur - validateur), ok mais il faudra le faire bien et à fond, cela implique aussi de mettre la bêta au placard. Un double sytème serait contreproductif.
• Se pose également le soucis de la communication du site au monde extérieur et des articles et tutos.

Mais je pense qu'il faut clairement recentrer la discussion ici sinon ça va s'étaler sur 60 pages et personne n'y comprendra plus rien.

Fondamentalement, le souci au niveau du staff se situe où ? (en tenant compte des contraintes IRL)

• Une partie des staffeux s'occupe aussi du dev. Ils ne peuvent donc par exemple valider à un rythme régulier parce qu'ils ont d'autres obligations qui fait que leur participation à la validation est potentiellement moindre ou en tous cas, variable.
• Une autre partie du staff s'occupe de la communication, idem.
• La partie restante se dédie complètement à la validation (c'est mon cas par exemple). Dans cette partie, certains membres sont absents et/ou inactifs.

Résultat ? Il difficile de compenser les absences et cela fait peser sur les staffeux qui participent une charge de travail accrue. L'on recrute, mais au final se reproduit : il faut constamment composer avec les absences ou les imprévus, les contraintes IRL, etc. C'est donc déjà très difficile à gérer. Tout ça, sur 24 staffeux.

Vous ajoutez une hiérarchisation par dessus tout ça ? C'est la mort du site sur le long terme.

Si l'on veut privilégier le rapport bilatéral (auteur- correcteur puis auteur - validateur), ok mais il faudra le faire bien et à fond,

Juste un détail : l’idée serait de faire le contraire. D’abord le contenu serait validé, ensuite seulement les correcteurs agréés corrigeraient la forme. Et cela parce que le validateur peut faire faire des changements sur le fond à l’auteur, qui nécessiteraient une nouvelle correction formelle.

C’est ce qui s’est fait pour Emeric (qui savait que son tuto allait être publié deux jours plus tard), sauf erreur de ma part. Pour les autres, c’est faute de pouvoir vraiment savoir quand le valido avait terminé son job que la correction est intervenue avant, mais ce n’est clairement pas optimisé.

Oui, ce serait effectivement mieux.

Edit : par contre, j'viens d'avoir une idée intéressante ! J'vais creuser un peu le sujet et voir si c'est viable. Mais ça n'a rien à voir avec ce sujet-ci donc je vais ouvrir un sujet propre.