Suivi — Modération Faire preuve de pédagogie envers les contributeurs de contenus

#1485 Posté par  (site web personnel) . État de l’entrée : ouverte. Licence CC By‑SA.
Étiquettes :
2
4
mar.
2015

(suite à une discussion avec des contributeurs due à des messages de refus non argumentés)

Il serait utile d'avoir une aide à la rédaction, lisible avant de contribuer, et pouvant être référencée dans un message de refus d'une dépêche par exemple.

Cette aide pourrait contenir des infos sur le style, le rappel des possibilités du Markdown, l'intérêt de mettre des images, de contextualiser (tout n'est pas en France, tout n'est pas à Paris, tout le monde ne connaît pas tel ou tel logiciel), d'éviter le style commercial ou le style parlé, les erreurs les plus courantes, le temps de modération, savoir qui contacter pour avoir de l'aide, l'utilisation des tags, éviter les liens "ici", avoir le lieu et la date complète dans le titre, etc., etc.

Sur http://linuxfr.org/proposer-un-contenu , on explique à quoi sert chaque type de contenu, et globalement pour la dépêche on permet de choisir entre « j'envoie direct en modération car j'ai déjà tout préparé » et « je vais en rédaction collaborative pour pouvoir être aidé, travailler à plusieurs, etc. » : permuter l'ordre serait sans doute un bien pour les nouveaux contributeurs.

La partie Aide du site ( http://linuxfr.org/aide ) ne contient pas (encore) d'aide à la rédaction.

Indirectement, la partie Règles de modération ( http://linuxfr.org/regles_de_moderation ) donne en creux ce qui sera refusé. Mais effectivement cette partie est tournée vers l'équipe du site plutôt que vers le contributeur.

Autre point :

  • en cas de rejet du contenu le contributeur ne voit que le message de refus, en espérant qu'il ait été personnalisé et qu'il détaille les problèmes du contenu. Il est peu probable qu'il soit en capacité de faire un diff entre la version soumise et la version sortant de la modération, et il n'a pas accès aux multiples corrections effectuées.
  • en cas d'acception du contenu, il n'a pas accès aux multiples corrections effectuées, et il n'y a donc pas de retour vers lui pouvant l'aider la prochaine fois (du style "Pense à bien choisir la section", "Tu as fait telle ou telle faute plusieurs fois dans le texte", "Tu devrais plutôt utiliser telle syntaxe Markdown pour mieux mettre en valeur", etc, etc.). Ainsi sur un événement du type "Le 3è jeudi du mois", on peut avoir les mêmes corrections à faire tous les mois, jusqu'à ce que quelqu'un se décide à contacter l'auteur.
  • # existant

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    Très bonnes idées ;-)

    Il y a quelques éléments à reprendre (ou plutôt à compléter) sur :

    Pour ceux qui approfondissent, ils peuvent tomber sur les pages Rédiger des dépêches noyau ou traductions classiques.

    Concernant la rédaction, plutôt que de l'intégrer à l'aide de LinuxFr.org qui n'est ensuite que difficilement modifiable… autant le laisser en collaboratif sur le wiki ?

  • # Diff de modération ?

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    Mettons qu'une dépêche partent en modération, et qu'elle est publiée. Dans ce cas, lorsque l'auteur reçoit un mél lui indiquant que sa dépêche à été acceptée, il pourrait également recevoir un fichier diff contenant la différence entre ce qu'il a envoyé en modération, et ce qui vient d'être publié.

    Chaque dépêche pourrait contenir un lien « correction de la modération », sur la ligne sous le titre.

    Ce n'est pas la panacée, mais ça permettrait un retour aux utilisateurs, sans demander plus de boulot aux modérateurs.

    Néanmoins, ça ne marcherait pas pour les refus. Mais peut-être que dans ce cas-là, quand le dépêche retourne en rédaction, le modérateur pourrait poster un petit message sur la dépêche concernée expliquant pourquoi elle a été refusée ?
    Il est également possible de demander à la tribune pourquoi une dépêche a été refusée.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.