Cette page est destiné à l'accueil d'un nouveau relecteur pour lui fournir les éléments de base et s'y retrouver au début

Il y a aussi des SuggestionsLecteurLinuxFR et SuggestionsArchiLinuxFR
Ci-dessous de l'aide pour ou des .

Modération vu du contributeur de la dépêche

• quel retour est fait à l'auteur de la dépêche ?
  • si sa dépêche est publiée un email lui est envoyé
  • si sa dépêche est refusée, un message de refus automatique avec un certain nombre de choix pour le modéro : déjà publié, trop court, pb d'orthographe, HS, etc. Le modérateur a la possibilité d'ajouter un message personnalisé (est obligé non ?)
  • Oumph : je penche en ce moment pour obliger à avoir un message personnalisé
• est-il parfois contacté pour lui proposer des ajouts afin d'étoffer sa dépêche ou préciser un point flou ?
  • Floxy : cf point précédent. on peut refuser pour demander une re-rédaction et là on précise souvent ce qui ne va pas à notre goût (on s'inspire des commentaires de tout le monde sur la tribune de la dépêche. Parfois, on les contacte aussi par email ou MP pour avoir plus de renseignements.
• un refus est-il systématiquement expliqué ? avec des raisons "standards" de refus ?
  • oui. cf https://linuxfr.org/moderateurs/moderation.html

Accueil d'un nouveau relecteur

• une petite page récapitulant ce qui est disponible en plus lorsqu'on est relecteur serait intéressante (là il faut découvrir les nouveaux liens qui apparaissent sur les pages), par exemple :
  • espace de discussion réduit (tribune) disponible sur la page d'accueil de linuxfr, historique plus long sur la page d'admin, de même pour chaque dépêche soumise il y a une tribune dédiée
    • typiquement une page d'aide avec le 'i' dans le rond bleu : c'est (ajouté sur SuggestionsLecteurLinuxFR)
  • un lien ADMIN à chaque dépêche permettant de modifier chaque dépêche (et de consulter sa tribune). Seuls les modérateurs sont habilités à effectuer une modification après approbation de la dépêche (relecteurs et modérateurs peuvent faire des modifications avant approbation).
  • une interface d'administration (page d'admin) avec Nouvelle(s) dépêche(s), Dépêches mises en attente, Dépêches effacées (30 dernières), Dépêches validées (30 dernières), lien vers les nouvelles astuces (éditables que par un modérateur), lien vers nouveaux sondages, lien vers les sections et thèmes actuels, liens vers des statistiques et la fréquentation.

• identifier les différences entre relecteur et modérateur
  • déjà préciser qu'un relecteur a pour vocation
    • d'éditer les dépêches (pour wikipédifier par exemple),
    • les vérifier et les préciser au besoin, notamment les liens (+ orthographe et grammaire, ça va de soi)
    • donner son avis :
    • les journaux ne sont pas concernés, même si un a été proposé, pouvoir pertinenter les articles, ou encore noter les journaux
    • il n'y a pas plus de droit accordé à un relecteur qu'à un simple utilisateur identifié du site (pas de karma en plus, pas de votes pour pertinentage/inutilage...), cela n'empêche pas de faire des commentaires (pertinents) pour autant
  • d'abord un contributeur pourra passer relecteur ce qui lui permet de participer à la modération des dépêches, donner son avis, revoir orthographe/grammaire et conformité à la
  • préciser comment sont choisis les relecteurs : par cooptation, sur demande de leur part, par leur participation à la vie du site linuxfr (pré-requis pour pouvoir passer relecteur) et du logiciel libre en général...
  • relecteur et modérateur ont possibilité d'ajouter des NdM avec parcimonie lorsque nécessaires
  • relecteur et modérateur donnent leur avis
    • contre la dépêche
    • pour la seconde page (SP)
    • pour la première page (PP)
  • un modérateur peut approuver une dépêche lorsque Seuil d'acceptation: > 5 [pour] ou la rejeter lorsque Seuil de refus: < -6 [contre]
    • NoNo : après lecture du code, je dirais que l'on calcule le [nombre de votes Pour] + [le nombre de votes Pour PP] - [nombre de votes Contre], et si le résultat est supérieur à 5, la dépêche est acceptable. Par contre, si le résultat est inférieur à -6, alors elle est refusable.
    • arachne : les seuils sont variables, ils sont calculés en fonction des votes des dépêches précédentes, un admin pour confirmer ?
      • NoNo : les seuils dépendent uniquement du nombre de modérateurs/relecteurs selon une formule compliquée
  • les modérateurs reçoivent les mails adressés à la liste de diffusion moderateurs at linuxfr dot org

• interface d'administration :
  • listes de Admins actuels, Modérateurs actuels, Relecteurs actuels, Possibilité d'être relecteurs (quand quelqu'un est proposé par un modérateur)
  • Nouvelle(s) dépêche(s) : les dépêches en attente de relecture / validation
  • Dépêches mises en attente : Servait avant la mise en place du système de vote et l'arrivée des relecteurs. on avait la possibilité de mettre une dépêche en attente (événement annoncé trop tôt, rédaction de dépêche collaborative par les modéros, etc)
  • Dépêches effacées (30 dernières des 90 derniers jours) : refus, Dépêches validées (30 dernières des 90 derniers jours) : celles acceptées, par exemple :
    • • [0] + [14/01 14:13] NFSv4 arrive à maturité (acceptable)
  • • le + indique une dépêche pour laquelle je n'ai pas exprimé de vote.
    • le [0] indique une dépêche sur laquelle il n'y a pas de commentaires (ceux-ci ne servent que très peu souvent, ils ne seront pas publiés et restent internes à l'admin, peut servir aux discussions internes).
    • un petit [!] apparaît quand un nouveau commentaire est fait dans la tribune d'un article

Statistiques sur les modérateurs

À notre époque, tout est benchmarké, même les modérateurs et relecteurs : https://linuxfr.org/stats/moderation.html

• Modérations : nombre de dépêches passées en SP ou PP ou refusées (à 0 pour les relecteurs bien sûr)
• Éditions : nombre d'éditions de dépêches effectuées, le Nombre de dépêches concernées est fourni (s'y reprendre à 2 fois pour effectuer les modifications est courant)
• Avis : il y a des champions pour donner leur avis

Ces chiffres sont pris sur 31 jours glissants pour vérifier qui est en vacances.

Questions diverses

• pourquoi les astuces ne sont-elles pas modérées plus vite ? (7 en attente actuellement)
  • Floxy : Seuls les modérateurs ont accès à la modération des astuces. de plus l'interface de modération des astuces est inergonomique au possible et ne propose pas les mêmes facilités que celle pour les dépêches. C'est pour ca que l'on est souvent si peu motivé. Et puis il faut pouvoir être sûr que l'astuce fonctionne.
• quelle est la différence entre une dépêche acceptable et une dépêche acceptée (idem pour refusable/refusée) ?
  • BAud : un modérateur est passé par là pour confirmer son statut "acceptée" (parfois avant qu'elle passe acceptable ou sur un 49.3 quand il n'y a pas assez de votants)

Dans les stats, ce serait pas mal d'avoir le délai min/moy/max (par mois) entre soumission de la dépêche et sa modération voire le nombre de celles modérées (acceptées) en moins de 6h, moins de 12h, moins de 1j, moins de 2j, > 2j (voire plus de détails si nécessaire)

• Oumph : on a 2 pages super lourdes à calculer dans l'interface d'admin, une sur les stats et l'autre sur la fréquentation, il faut les calculer une fois par jour et les mettre en cache... Après elles pourraient même être publiques.
• BenoitAudouard : Une fois par semaine ça peut déjà suffire, c'est surtout pour les fanas de stats comme moi
• NoNo : pour ce genre de demandes, il est préférable d'utiliser le tracker. C'est plus simple pour les admins. Merci.

Proposition d'ajouts à règles de modération

Pour https://linuxfr.org/moderateurs/moderation.html voici quelques suggestions d'ajouts :

• Rejeter les dépêches non rédigées -
  • j'apprécie quand la seconde partie de la dépêche est aérée en paragraphes et apporte un peu de développements / questionnements à la dépêche. C'est l'approfondissement de la dépêche ou un extrait des points marquants des liens proposés dans la dépêche (pour ceux qui ne voudraient pas tout lire).
• Éviter les doublons -
  • ajouter que cela arrive aussi lorsqu'un sujet du moment est soumis par plusieurs contributeurs, ou suite à une mauvaise manip'
  • comment peut être effectué une fusion des informations si elles sont complémentaires ?
    • Oumph : précise ce que tu veux. Tu veux indiquer une méthode ou fournir une solution technique ? En pratique on ouvre toutes les dépêches dans des onglets et on pioche dans toutes moins une pour complèter la dernière. On remercie tout le monde. Ensuite on rejette les toutes moins une et on diffuse l'autre.
    • BenoitAudouard : méthode, tout n'étant pas informatisable ; ça correspond à ce que je pensais.
  • lorsqu'une dépêche est finalement retenue, penser à remercier les autres qui l'ont soumises (comme cela est souvent fait)
• Éviter les acronymes -
  • suggérer le format : soit le terme et son acronyme entre parenthèse (mieux a priori), soit l'acronyme et sa signification entre parenthèse.
  • ajouter un lien vers une page de Wikipedia est pertinent (si elle existe) pour ceux qui veulent approfondir ou vers le site web pour un organisme (par exemple la FSF)
• Agenda du libre
  • pour vos infos locales (first jeudi, install' party, événement ponctuel) n'oubliez pas de vous inscrire sur http://agendadulibre.org/
• Jeux Libres
  • pour les annonces de jeux sur LinuxFR penser au préalable à créer (ou mettre à jour) la fiche sur http://jeuxlibres.net

Processus de modération de dépêche

Pour la modération de dépêche, AMHA il y a deux points de vue à présenter :

• expliquer le process aux contributeurs (ça leur permet de comprendre les critères utilisés pour retenir leur dépêche) => déjà aux 3/4 fait (ajouter qu'il sera prévenu si sa dépêche est rejetée ou doit être complétée ou sinon qu'elle sera acceptée en l'état, qu'au besoin il peut contacter les modéros...)
  • en SP : toutes les dépêches d'Infos Locales (sauf lorsque l'événement est particulièrement intéressant) ou les dépêches moins rédigées ou sur un sujet ne passionnant pas tout le monde (ça arrive) ou une version mineure de logiciel
  • en PP : les dépêches de Revue de Presse (dont revue de presse de l'April), annonces de Intelli'N tv, annonces de LinuxMAO, les dépêches kernel et plus spécifiquement toutes les versions majeures de logiciel, les poissons d'avril, les appels à tests (cela leur donne plus de visibilité), les releases de distributions...
• la check-list pour un modéro (une extensive et une réduite), répondre oui à chacun des rappels ci-dessous (sinon agir !)
  • le titre est-il bon ? c'est particulièrement important car il apparaît dans les fils RSS (et certains s'arrêtent à cela...) : par exemple "AMD/ATI va libérer ses pilotes" => est-ce vraiment l'information ? (ou plutôt AMD/ATI va peut-être travailler à tenter de libérer un jour (de la semaine des 4 jeudis) des pilotes...)
  • bon choix de la section pour la dépêche (notamment pour Infos Locales et Logiciel, qui n'ont rien à faire en Article),
  • exactitude des liens + langue (drapeau) si un lien n'a pas été cliqué (il est à 0 clic), cela empêche que la dépêche soit publiée, il faut vérifier ;-)
  • orthographe, complétude de la dépêche, conformité à la charte (véracité)
  • bonne aération des paragraphes de la zone grisée du détail de la dépêche, liens vers Wikipedia (ou autre) pour acronymes
  • Note du Modérateur (NdM) pour préciser/clarifier, vérifier de ne pas changer le sens et de ne pas générer de troll non souhaité (rester factuel)
  • re-vérifier l'orthographe (noms, ...) et les liens des fois qu'il y ait des précisions à ajouter à la dépêche
  • relire la tribune associée à la dépêche pour vérifier que tout a été pris en compte ainsi que le journal qui l'a précédé (s'il y en a eu un)
  • pour un refus : laisser un modérateur prévenir l'auteur ?
  • envisager les trolls ou les points imprécis/flous/inexacts
  • remerciements - si nécessaire - de ceux qui ont proposé une dépêche similaire
• seuil haut = nombre de gens pouvant voter et étant passés depuis moins de 4 jours / 5 (utile quand il y a moins de monde présent... genre à Noël)
• pour les Infos Locales, des critères spécifiques sont appliqués :
  • les copier/coller sont acceptés dès lors que le texte est suffisamment synthétique (pas de gros pavés) et adapté au style de LinuxFr, en temps normal les copier/coller sont refusés pour deux raisons :
    • lorsque l'auteur de la dépêche n'est pas l'auteur du texte initial, cela peut poser un souci de droit d'auteur (risque mineur dans le libre, moins dans d'autres cas où seules les courtes citations sont autorisées par la loi)
    • la rédaction n'est pas adaptée à l'audience de LinuxFr (c'est surtout le cas des communiqués de presse dont le ton n'est pas de bon aloi et reconnaissable à 10 km, une personnalisation est quasi-systématiquement demandée)
  • il est recommandé d'inscrire l'événement sur l'agenda du libre http://agendadulibre.org (ou ses pendants québecois ou belge) au préalable
  • ajouter le lien vers l'AdL s'il a été oublié (au pire vers le mois en cours si pas encore modéré sur l'AdL, rappeler cette règle au besoin dans les commentaires si l'AdL n'a pas été renseigné : cela permet d'avoir une vue par GULL / lieu / date et est un indicateur de l'activité du libre par région et thème)
  • exiger^Wdemander un regroupement clair de dépêches aux GULL ayant des activités récurrentes

Processus d'attribution des prix aux meilleurs contributeurs

Les meilleurs contributeurs peuvent se voir attribuer chaque mois un certain nombre de prix (Livres et abonnements).
cf. ProcedureAttributionPrizes

Éditer une dépêche

• la remise en forme d'une dépêche peut permettre de la rendre plus lisible, notamment
  • utilisation de <ul><li>1ère ligne</li><li>2ème ligne</li></ul> (par exemple pour les changelogs ou les listes de fonctionnalités) penser à enlever les retours chariot sinon la mise en forme est un peu trop aérée
    • Astuce copier / coller </li><li> en début de ligne
    • suffit de compléter avec <ul> et </ul> en début et fin...( ou <ol> </ol> pour une liste numérotée, ça permet de garder lisible la dépêche dans la zone d'édition et éviter les retours chariots qui seraient autrement malencontreusement insérés dans les listes à puce/numérotées... (faut le voir pour le croire, mais ça marche)
  • ajout de liens vers http://agendadulibre.org pour les dépêches concernant la communauté (au pire en prenant le mois concerné si l'annonce n'est pas encore parue)
  • ajout de liens vers http://jeuxlibres.net pour les jeux vraiment libres (c'est un bon indicateur si les données sont effectivement libres ou seulement le moteur), les liens vers les copies d'écran devraient être obligatoires
  • ajout de liens vers wikipedia (par exemple) pour les termes technique ou les acronymes
    • <a href="http://fr.wikipedia.org/wiki/Linus_Torvalds">Linus Torvalds</a> (oui oui un guillemet de chaque côté de l'URL est indispensable pour la conformité XHTML 1.0)
      • Astuce pour les acronymes tel que IMAP il y a aussi http://fr.wikipedia.org/w/index.php?title=IMAP&redirect=no qui donne directement le lien pour avoir un acronyme directement pour IMAP (enfin c'est comme ça que je l'utilise)
    • sinon <acronym title="Note des modérateurs">NdM</acronym> pour ajouter la signification d'un acronyme (souligné et visible dans une info-bulle par survol)
    • la syntaxe wikipedia a été ajoutée [[Lien]] permet d'ajouter le texte Lien pointant vers http://fr.wikipedia.org/wiki/Lien
      • cela fonctionne pour les journaux (pas encore pour les dépêches IIRC et ne supporte pas les espaces ou les caractères non ascii, pour l'espace un souligné "_" peut fonctionner sans être trop visible, pour les autres caractères essayer [[%C3%89l%C3%A9ment_HTML]] pour afficher %C3%89l%C3%A9ment_HTML n'est pas optimal :/)
      • [[en:Link]] permet de renvoyer vers Link le mot dans la partie anglaise de wikipedia
  • entourer un lien de crochets comme pour [http://wiki.eagle-usb.org/wakka.php?wiki=SuggestionsRelecteurLinuxFR#editer] permet de protéger l'url des parenthèses ou autres ponctuations reconnues par la regexp
• une NdM permet de préciser un point de vue ajouté par un modérateur (signaler qu'une techno est non libre notamment, donner les équivalents en libre) ou un complément notable à la dépêche
• ne pas hésiter à ajouter une NdM en 2ème partie pour détailler un aspect méritant d'être expliqué (souvent oublié par l'auteur de la dépêche tellement ça lui semble évident)
• amélioration éventuelle : lorsqu'un relecteur pose un verrou pour éditer une dépêche, à la sauvegarde il n'y a pas passage par le correcteur orthographique, d'où de multiples éditions...
  • en ce qui me concerne j'ouvre le lien dans une nouvelle fenêtre (ce qui me permet de voir les erreurs d'orthographe)
  • bien souvent je fais 2-3 éditions pour orthographe et mise en forme, pas forcément bons du 1er coup...
• la liste complète des balises (uniformisée avec journal) : a,p,b,i,s,u,em,tt,strong,ol,ul,li,pre,code,q,blockquote,acronym.
  • le <pre>ascii art</pre> permet d'avoir l'affichage des espaces et une police à taille fixe (utile pour l'ascii art)
  • il manque le &nbsp; pour l'espace insécable (mais il pourrait être ajouté automatiquement devant :, !, ? et ; ainsi que « et »)
• Ne pas oublier de mettre un commentaire d'édition explicite, pour avoir un suivi de l'édition.

Règles tacites

• En tant que relecteur ou modérateur, ne pas éditer ses propres dépêches (c'est parfois mal vu des lecteurs) : signaler dans la partie administration les erreurs flagrantes ou modifications qui resteraient (il est toujours possible d'utiliser un wiki pour préparer la rédaction d'une dépêche en commun comme pour les revues de presse). Il y a bien sûr quelques exceptions (lorsque le travail de mise en forme est trop important par exemple). Il est explicitement recommandé dans les règles de modération de ne pas modérer ses propres dépêches.
• Afin de faciliter le travail des modérateurs, il est demandé aux relecteurs de ne pas voter [pour] une dépêche tant qu'il reste des fautes flagrantes ou qu'il y a un besoin de mise en forme : la tribune d'administration de la dépêche est là pour le signaler et faire des propositions. Note : Il a été a refusé plusieurs fois un système de double validation (recommencer le vote après une très grosse modif par exemple) parce que ça risquait de mettre trop longtemps en attente certaines news quand peu de modéros sont dispos.
• pour les infos locales, si la date de l'événement est à plus d'un mois, refuser en demandant de resoumettre 2 semaines avant + inscription à l'AdL (Agenda du Libre) au préalable. Un appel à conférenciers ou une conférence à l'étranger (Fosdem) demandant un peu plus de planification font bien sûr exception...
• Les interview de Floxy et les dépêches de patrick_g (linux kernel, gcc...), ça rox. Faut les mettre automatiquement en PP :)

Abbréviations communes

et leur utilisation généralement admise

• PP : Page Principale
• SP : Seconde Page
• PPP : Première Page Phare. Case juste au dessus de la dépêche en tête de ligne, un peu moins visible mais permet de remonter une dépêche intéressante tombée dans l'oubli. Tacitement c'est la dépêche à la Une.
• CCPP : Comité Contre une Phrase par Paragraphe
• bêta : http://fr.wikipedia.org/wiki/B%C3%AAta pour une version de logiciel encore en test
• _o/* BLAM ! _o/* paf ! interjections communes sur https://linuxfr.org/board/ (voir SuggestionsTribuneLinuxFR pour plus de précisions)

Discussions internes

• impacts de DADVSI sur linuxfr
• des stats pour l'historique de Juin 2007 http://eagle-usb.org/images/linuxfr/index20070630.html
• à améliorer et promouvoir
  • ajouter une boîte affichant l'espace rédacteur (à choisir dans les https://linuxfr.org/user_prefs.html) accessible pour tout le monde
  • revoir aussi https://linuxfr.org/plan/ pour mettre en avant ce qui est utile (il manque l'espace rédacteur par exemple)
  • détailler un peu mieux le processus de modération et le processus de rédaction (celui-ci étant externe actuellement, hormis un petit peu avec l'espace rédacteurs)
  • adjoindre un wiki admodérolecteur https://linuxfr.org/tracker/605.html (+ rédacteur àmha)

Liens intéressants

• le wiki pour la revue de presse : NewsRevueDePresse
• Pour la rédaction collaborative de dépêches : NewsLinuxFr (en attendant que le soit opérationnel)
• La ligne éditoriale et ses liens utiles : https://linuxfr.org/moderateurs/moderation.html#ligne
• Suivi des dépêches traitant de migration vers GNU/Linux : http://chl.be/migrations/ (peut-être intéressant à rajouter sur ce genre de dépêches pour montrer la progression)
• Affichage des dépêches par jour : https://linuxfr.org/2006/01/03/ (utile pour le récapitulatif de début d'année)

---