Extension:Moderation

This page is a translated version of the page Extension:Moderation and the translation is 99% complete.
Other languages:
English • ‎Türkçe • ‎dansk • ‎français • ‎中文 • ‎日本語
Manuel des extensions MediaWiki
OOjs UI icon advanced-invert.svg
Moderation
État de la version : stable
Special Moderation screenshot.png
Implémentation Page spéciale
Description Envoie toutes les modifications et téléchargements de nouveaux utilisateurs à la modération.
Auteur(s) Edward Chernenko
Dernière version 1.5.35 (2021-06-26)
Politique de compatibilité Le master conserve la compatibilité arrière.
MediaWiki 1.31+ (master branch)

1.27-1.30 (REL1_27 branch)

1.23-1.26 (REL1_23 branch)
PHP 7.0+
Modifications de
la base de données
Oui
Tables moderation
moderation_block
Licence Licence publique générale GNU v3.0 ou ultérieur
Téléchargement

  • $wgModerationEnable
  • $wgModerationTimeToOverrideRejection
  • $wgModerationOnlyInNamespaces
  • $wgModerationIgnoredInNamespaces
  • $wgModerationNotificationEnable
  • $wgModerationEmail
  • $wgModerationNotificationNewOnly

  • moderation
  • skip-moderation
  • skip-move-moderation
  • moderation-checkuser
Traduire l’extension Moderation

Vérifier la matrice des utilisations et des versions.

L'extension "Modération" offre une protection contre le vandalisme pour les wikis de petite et moyenne taille.

C'est "l'une des méthodes de protection anti-vandalisme les plus efficaces" et cela a très peu d'impact sur les utilisateurs légitimes.

Introduction

Comment ça marche ?
  1. Chaque modification (ou téléchargement d'image) par un nouvel utilisateur est envoyé à une file d'attente de modération.
  2. Jusqu'à ce que le modérateur approuve cette modification, la page reste inchangée. Les modifications en attente ne figurent ni dans l'historique des pages ni dans les ModificationsRécentes.
  3. L'utilisateur peut voir sa modification et continuer à modifier sa propre version de la page.
Comment les administrateurs modèrent ?
  1. Une nouvelle page spéciale est fournie (Spécial : Modération). C'est un peu comme les ModificationsRécentes, mais a "Approuver", "Rejeter", "Approuver tout" et "Rejeter tout" boutons.
  2. Les modifications rejetées vont dans l'archive rejetée.
  3. Les modifications approuvées sont appliquées normalement.
  4. Les journaux de "qui a approuvé quoi" sont maintenus. Seuls les modérateurs peuvent les voir.
  5. Si un conflit d'édition est détecté et qu'il ne peut pas être résolu automatiquement, le modérateur a un bouton de fusion pour appliquer l'édition manuellement.
Pourquoi est-ce bon ?
  1. Les nouveaux utilisateurs ne sont pas découragés par l'ennuyeux captchas , la vérification des numéros de téléphone, etc. Ils éditent normalement, comme ils le feraient dans MediaWiki sans modération.
  2. Les blocs deviennent pratiquement obsolètes. Et les blocs ne sont pas bons (considérez la possibilité de frapper un utilisateur légitime avec un bloc de plage, ou l'incapacité de permettre de bonnes modifications d'un utilisateur pas très adéquat qui a parfois l'envie de vandaliser une page ou deux).
  3. Le vandalisme pour "vouloir être remarqué" est découragé. Personne ne resterait assis pendant 5 heures à la recherche de nouveaux proxies pour mettre l'administrateur en colère, s'il est connu que toutes ces actions ne sont pas un problème.
  4. Les méthodes de vandalisme comme "vandaliser une page à partir de deux comptes pour empêcher la restauration d'un clic" ne sont plus efficaces.
  5. Le site peut fonctionner dans des réseaux anonymes comme TOR ou I2P.

Alternatives

 
Journal de modération

MediaWiki a-t-il d'autres méthodes de contre-vandalisme ? Bref, "pas vraiment".

MediaWiki a été développé pour Wikipedia. A tout moment, Wikipédia compte des centaines de bénévoles prêts à revenir au vandalisme en temps réel. Presque tous les autres wiki à part Wikipedia n'ont pas ce genre d'avantage. L'idée de contre-vandalisme de MediaWiki est que le vandalisme prend plus de temps que de le renverser. Normalement, c'est vrai, mais cela n'aide pas à décourager le vandalisme, et les administrateurs doivent encore souvent rechercher le vandalisme, même si le retour en arrière lui-même ne prend pas beaucoup de leur temps.

Il existe "trois méthodes connues pour combattre le vandalisme" :

  1. Rendre toutes les corrections difficiles''. Par exemple, Lurkmore.to impose un captcha fort sur toutes les modifications de nouveaux utilisateurs, et il faut beaucoup de modifications pour pouvoir enfin éditer sans le captcha. Par conséquent, le vandale doit passer beaucoup de temps à faire quelques modifications.
  2. : Le moins évident est que tous les utilisateurs légitimes doivent contourner le captcha ainsi, ce qui pourrait décourager les modifications mineures comme correctifs d'orthographe.
  3. Enforce user identification - par exemple, connexion via Facebook. Si le réseau social vérifie que tous ses utilisateurs ont un numéro de téléphone portable valide, alors chaque tentative de vandalisme demande au vandalisme d'aller au magasin et d'acheter une nouvelle carte SIM. Si le réseau social vérifie que tous ses utilisateurs ont un numéro de téléphone portable valide, alors chaque tentative de vandalisme demande au vandalisme d'aller au magasin et d'acheter une nouvelle carte SIM.
    A strong minus of this method is the impact on users' privacy. Dans les pays non démocratiques, éditer une page sur la politique peut amener le gouvernement à essayer d'identifier et de persécuter l'utilisateur. Par exemple, Lurkmore.to a été contacté par la Russie "force spéciale anti-extrémiste" avec des demandes de divulgation d'informations sur les auteurs de pages sur Ramzan Kadyrov et le cocktail Molotov.[1]
  4. Atténuer les résultats du vandalisme''. Par exemple, un utilisateur peut créer 100 pages avec des titres offensants, mais ils peuvent tous être supprimés par deux clics dans Extension:Nuke . L'extension de modération appartient à cette catégorie.

Cette extension est-elle stable ?

Cette extension est "stable". Il est déployé en production sur le site russe Uncyclopedia (absurdopedia.net) depuis novembre 2014.

L'extension a une suite de tests automatisés avec une couverture significative (phpunit et [$sélénium Selenium]). Chaque modification à la modération est automatiquement testée sur:

  1. nouvelle version de MediaWiki
  2. MediaWiki 1.35 (LTS)
  3. MediaWiki 1.31 (Ancien LTS (support à long terme))

Veuillez lire les fichiers KNOWN_LIMITATIONS, TODO et WONT_DO pour tous les problèmes connus. N'hésitez pas à contacter l'auteur si vous avez des questions.

Quelle est la différence entre les versions avec indicateur ou approuvées ?

Extension:FlaggedRevs/fr et Extension:Approved Revs masquent les mauvaises révisions seulement des lecteurs. Les éditions vandales existeront toujours dans l'histoire et les ModificationsRécentes, et tous les éditeurs tomberont dessus quand ils essaieront de modifier la page qui a été vandalisée. Les administrateurs doivent donc rapidement mettre fin au vandalisme.

D'autre part, Modération élimine complètement les modifications vandales : les révisions non approuvées ne sont tout simplement pas créées dans l'historique des pages, etc. Cela garantit que non seulement les lecteurs, mais aussi les autres éditeurs ne verront pas les modifications de vandale dans aucune des pages.

En bref, (1) FlaggedRevs est pour le contrôle de la qualité mais n'aide pas contre le vandalisme persistant. (2) La modération est spécifiquement contre le vandalisme et le rend complètement inefficace.

Modération FlaggedRevs/ApprovedRevs
Les lecteurs voient-ils le vandalisme ? Non Non
Les lecteurs voient-ils le vandalisme ? Non Oui
Le vandalisme reste-t-il dans l'histoire des pages ? Non Oui
Peut rejeter rapidement toutes les modifications par l'utilisateur ? Oui Non
D'autres éditeurs peuvent-ils améliorer les modifications non approuvées ? (pas du vandalisme) Non Oui

Installation

For modern versions of MediaWiki (1.31+), use the following instruction:

Cette extension doit être activée en dernier dans votre fichier "LocalSettings.php" après tous les autres paramètres et extensions.

Installation for older versions of MediaWiki

For MediaWiki 1.27-1.30, replace the above-mentioned "git clone" command with the following: git clone -b REL1_27 https://github.com/edwardspec/mediawiki-moderation.git

For MediaWiki 1.23-1.26, replace the above-mentioned "git clone" command with the following: git clone -b REL1_23 https://github.com/edwardspec/mediawiki-moderation.git

Ces versions peuvent encore recevoir des corrections de sécurité (le cas échéant), mais pas de nouvelles fonctionnalités.

Configuration

Paramètres pour LocalSettings.php

  • $wgModerationEnable
    Si la valeur est "false", les nouvelles modifications sont appliquées comme d'habitude (non envoyées à la modération). Valeur par défaut : true.
    $wgModerationTimeToOverrideRejection
    Temps (en secondes) après lequel la modification rejetée n'a plus pu être approuvée. Valeur par défaut : "2 semaines". Note : les anciennes modifications rejetées ne sont PAS supprimées (les modérateurs peuvent toujours les regarder dans le dossier Rejeté même si cette fois est terminée).
    $wgModerationOnlyInNamespaces
    S'il est défini sur un tableau de numéros d'espace de noms (p.ex. $wgModérationOnlyInNamespaces = [ NS_MAIN, NS_FILE ];), la modération n'est activée que dans ces espaces de noms (les modifications apportées dans d'autres espaces de noms contournent la modération). Valeur par défaut (tableau vide) : la modération est activée partout.
    $wgModerationIgnoredInNamespaces
    S'il est défini sur un tableau de numéros d'espace de noms (p.ex. $wgModérationIgnoredInNamespaces = [ NS_MAIN, NS_FILE ] ; ), les utilisateurs non automatisés peuvent contourner la modération dans ces espaces de noms. Valeur par défaut (tableau vide) : la modération ne peut être contournée nulle part.
    $wgModerationNotificationEnable
    Si la valeur est true, un e-mail de notification est envoyé à $wgModerationEmail chaque fois qu'une modification est mise en file d'attente pour modération. Valeur par défaut : false.
    $wgModerationNotificationNewOnly
    Si la valeur est true, vous ne devez informer que des nouvelles pages (mais pas des modifications apportées aux pages existantes). Valeur par défaut : false.

Voir aussi : #Options de configuration UNIQUEMENT pour la révision avant publication (options non recommandées pour 95 % des wikis).

Droits utilisateur

Droit Que peut faire l'utilisateur ? Qui a ce droit ? (par défaut)
skip-moderation Les modifications sont appliquées comme d'habitude (non envoyées à la modération). automoderated, sysop, bot
skip-move-moderation Page moves are applied as usual (not sent to moderation). automoderated, sysop, bot
moderation Peut accéder Spécial : Modération moderator, sysop
moderation-checkuser Can see IPs of registered users on Special:Moderation. checkuser

Conseils supplémentaires contre le vandalisme

Afin de prévenir le vandalisme, les mesures supplémentaires suivantes devraient être appliquées :

  1. S'il vous plaît limit le renommage des pages à un groupe de confiance (pas seulement "automatisé"), parce qu'il peut être utilisé pour le vandalisme difficile à rétablir.
    $wgGroupPermissions['automoderated']['skip-move-moderation'] = false;
    $wgGroupPermissions['sysop']['skip-move-moderation'] = true;
    
  2. L'enregistrement de nouveaux comptes avec des noms offensants est toujours un moyen pour un vandale de se montrer dans les ModificationsRécentes. Une solution simple consiste à supprimer le journal des nouveaux utilisateurs de ModificationsRécentes : solution de $

Utilisation recommandée / bonnes pratiques =

Les bonnes pratiques suivantes sont recommandées :

  1. Seul le vandalisme doit être rejeté. Les modifications moins bonnes avec de bonnes intentions (par exemple, ajouter des détails d'intrigue excessifs dans l'article de Wikipedia sur le film) sont mieux faites Approuvé et ensuite réverti comme d'habitude. De cette façon, l'auteur n'est pas offensé et le texte est sauvegardé dans l'historique des pages, visible par quiconque.
  1. Any user that is deemed legitimate (does N good edits) should be added into automoderated group.
  1. Ajouter des utilisateurs à automoderated groupe via $wgAutopromote n'est PAS recommandé, car cela motive les vandales à faire de nombreuses modifications très mineures (par exemple, ajouter interwiki). Mieux les promouvoir à automoderated manuellement pour un bon montage et non pas promouvoir pour 30 édits inutiles-fait-pour-compte.
  2. Abstenez-vous d'utiliser blocks . Ne protect pages pas "juste au cas où", sauf peut-être pour les modèles importants.
  3. Permettre la réhabilitation complète des utilisateurs avec un mauvais historique d'édition. Leurs modifications utiles aux articles devraient être autorisées, peu importe le nombre de fois où ils ont été bloqués. Dans le même temps, les trolls sur les pages de discussion devraient être rejetés, de même que les éditions volontairement de mauvaise qualité.

Utilisation non recommandée : Modération en tant qu'extension de révision avant publication

La modération est d'abord un outil anti-vandalisme, mais certains wikis l'utilisent pour contrôler la qualité. Par exemple, un wiki d'oeuvres scientifiques pourrait choisir de :

  1. Ne pas approuver les modifications tant qu'elles ne répondent pas aux normes de qualité strictes de l'industrie.
  2. Not Rejeter les modifications qui ne sont pas "pas encore assez bonnes", afin que l'auteur puisse continuer à les éditer aussi longtemps que nécessaire.

Avantages de cette approche :

  1. Nouvelle page apparaît comme un document entièrement revu, correctement formaté, sans coquilles, etc.
  2. Personne à part l'auteur et les modérateurs ne verraient les révisions imparfaites.

Inconvénients :

  1. Les autres utilisateurs ne peuvent pas améliorer l'article tant qu'il n'est pas approuvé. En fait, ils ne sauront même pas que ça existe.
  2. Les modifications en attente n'ont pas d'historique de modification. Modération ne stocke qu'1 modification en attente pour chaque paire Page/Utilisateur. Cela n'est pas pratique si vous préparez votre page pour la publication pendant des semaines. L'utilisateur peut même supprimer accidentellement le texte nécessaire dans sa révision en attente, et il ne sera pas récupérable.

Options de configuration UNIQUEMENT pour la révision avant publication

Les paramètres suivants sont uniquement nécessaires lors de l'utilisation de la Modération pour la révision. Ils ne sont pas recommandés pour 95 % des wikis (lorsqu'ils suivent les meilleures pratiques, ils ne sont absolument pas nécessaires).

  • $ModérationPreviewLink
    Si 'true, le lien Aperçu s'affiche sur Special : Modération. Valeur par défaut : false.
    Pourquoi pas recommandé ? "Réponse" : lorsque vous suivez les meilleures pratiques, vous ne rejetteriez jamais une bonne modification simplement parce qu'elle est mal formatée. Que cette modification soit bonne ou non, vous le savez à partir du lien "diff". Le lien "Aperçu" vous indique "comment cette page est formatée", ce qui ne devrait pas affecter votre décision.
    $ModérationEnableEditChange
    Si true, les modérateurs peuvent modifier le texte des modifications en attente avant d'approuver. Valeur par défaut : false.
    Pourquoi pas recommandé ? "Réponse" : facile à gâcher. Modérateur peut accidentellement supprimer le texte de la modification en attente (et il ne sera pas récupérable). De plus, ces changements ne sont pas attribués à un modérateur (après approbation, on dirait que l'auteur original a fait l'édition de cette façon), ce qui est flippant."

Compatibilité avec d'autres extensions

  1. Extension : La modération doit être activée last dans LocalSettings.php, car elle abandonne au moins PageContentSave hook.
  2. Extension : Modération prend entièrement en charge Extension:CheckUser , ce qui signifie que si l'extension CheckUser est activée, alors toute modification approuvée aura IP, user-agent et XFF corrects enregistrés dans les tables checkuser.
  3. Extension : Modération est entièrement compatible avec Extension:VisualEditor et Extension:MobileFrontend . Théoriquement, il devrait également fonctionner avec d'autres éditeurs basés sur API.
  4. Extension:StructuredDiscussions (également connu sous le nom de Flow) et Extension:CommentStreams fonctionnera, mais les modifications dans les forums Flow/CommentStreams contourneront la modération.
  5. : La modération des forums de flux doit être implémentée dans Extension : StructuredDiscussions. Ces forums utilisent un non-texte "content model", qui n'est pas pris en charge par Modération.
    CommentStreams extension misinterprets "edit was queued for moderation" as an error, which can only be fixed in Extension:CommentStreams itself.
  6. Les extensions qui modifient plusieurs slots de Multi-Content Revisions (pas seulement le slot principal, comme MediaWiki lui-même le fait) ne sont pas encore supportées. (actuellement très peu d'extensions le font)

Voir aussi