Extension:Moderation
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 ?
- Chaque modification (ou téléversement d'image) par un nouvel utilisateur est envoyé à une file d'attente de modération.
- 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 modifications récentes.
- L'utilisateur peut voir sa modification et continuer à modifier sa propre version de la page.
- Comment les administrateurs modèrent-ils ?
- Une nouvelle page spéciale est fournie (Special:Moderation). C'est un peu comme les ModificationsRécentes, mais avec les boutons "Approuver", "Rejeter", "Approuver tout" et "Rejeter tout".
- Les modifications rejetées vont dans l'archive des rejets.
- Les modifications approuvées sont appliquées normalement.
- Les journaux de "qui a approuvé quoi" sont maintenus. Seuls les modérateurs peuvent les voir.
- 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 ?
- Les nouveaux utilisateurs ne sont pas découragés par les ennuyeux captchas, les vérifications des numéros de téléphone, etc. Ils modifient normalement, comme ils le feraient dans MediaWiki sans modération.
- Les blocages deviennent pratiquement obsolètes. Et les blocages ne sont pas bons (considérez la probabilité d'atteindre un utilisateur légitime dans bloc d'adresses bloquées, 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).
- 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.
- 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.
- Le site web peut fonctionner dans des réseaux anonymes comme TOR ou I2P.
- Users can hide their mistakes from appearing in the revision history and even from moderators by fixing them in time.
- Since any edit is only permanently recorded upon approval, users can correct botched edit summaries.
Alternatives
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 son annulation. 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 :
- Rendre toutes les modifications difficiles. Par exemple, Lurkmore.to impose un captcha fort sur toutes les modifications venant des 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 de multiples modifications.
- 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.
- Renforcer l'identification des utilisateurs - par exemple, se connecter 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 vandale d'aller au magasin et d'acheter une nouvelle carte SIM. Cette méthode est très efficace, bien qu'elle élimine les modifications anonymes et éloigne les utilisateurs qui n'ont pas de compte sur un réseau social quelconque.
- Un inconvénient majeur de cette méthode est l'impact sur la vie privée des utilisateurs. 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 « force spéciale anti-extrémiste » russe avec des demandes de divulgation d'informations sur les auteurs des pages sur Ramzan Kadyrov et le cocktail Molotov.[1]
- 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 en 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 de la modération est automatiquement testée sur :
- nouvelle version de MediaWiki
- MediaWiki 1.35 (LTS)
- 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 et Extension:Approved Revs masquent les mauvaises révisions seulement aux lecteurs. Les modifications des vandales existeront toujours dans l'historique et dans les ModificationsRécentes, et tous les éditeurs les verront quand ils essaieront de modifier la page qui a été vandalisée. C'est pourquoi les contributeurs doivent rapidement annuler le vandalisme.
D'autre part, Modération élimine complètement les modifications des 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 des vandales 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 contributeurs voient-ils le vandalisme ? | non | oui |
| Le vandalisme reste-t-il dans l'historique des pages ? | non | oui |
| Peut-on rejeter rapidement toutes les modifications d'un utilisateur ? | oui | non |
| D'autres éditeurs peuvent-ils améliorer les modifications non approuvées ? (qui ne sont pas du vandalisme) | non | oui |
Installation
Pour les versions modernes de MediaWiki (1.35+), utilisez l'instruction suivante :
- Extraire les sources avec
git clone https://github.com/edwardspec/mediawiki-moderation.gitet placez le(s) fichier(s) dans un répertoire appeléModerationdans votre dossierextensions/. - Ajoutez le code suivant à la fin de votre fichier LocalSettings.php :
wfLoadExtension( 'Moderation' );
- Exécutez le script de mise à jour qui va créer automatiquement les tables de base de données dont cette extension a besoin.
Fait – Accédez à Special:Version sur votre wiki pour vérifier que l'extension a bien été installée.
Installation pour d'anciennes versions de MediaWiki
For MediaWiki 1.35-1.38, replace the above-mentioned "git clone" command with the following:
git clone -b REL1_35 https://github.com/edwardspec/mediawiki-moderation.git
Pour MediaWiki 1.31-1.34, remplacer la commande git clone ci-dessus par :
git clone -b REL1_31 https://github.com/edwardspec/mediawiki-moderation.git
Pour MediaWiki 1.27-1.30, remplacez la commande "git clone" mentionnée ci-dessus par ce qui suit :
git clone -b REL1_27 https://github.com/edwardspec/mediawiki-moderation.git
Pour MediaWiki 1.23-1.26, remplacez la commande "git clone" mentionnée ci-dessus par ce qui suit :
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
<span id="Parameters_for_LocalSettings.php">
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 ne peut plus ê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 voir dans le dossier Rejected même si le délai est échu).
- $wgModerationOnlyInNamespaces
- S'il est défini sur un tableau de numéros d'espace de noms (p.ex.
$wgModerationOnlyInNamespaces = [ 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.
$wgModerationIgnoredInNamespaces = [ 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 courriel de notification est envoyé à $wgModerationEmail (par exempe$wgModerationEmail = 'send.to.this.address@example.com';) 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 pour les 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
This extension adds two groups (automoderated and moderator), which have the following rights:
| Droit | Que peut faire l'utilisateur ? | Qui a ce droit ? (par défaut) |
|---|---|---|
skip-moderation
|
Les modifications sont appliquées comme d'habitude (c'est à dire non envoyées à la modération). | automoderated, sysop, bot |
skip-move-moderation
|
Renommage des pages sont appliqués comme d'habitude (pas envoyés à la modération). | automoderated, sysop, bot |
moderation
|
Peut accéder à Special:Moderation | moderator, sysop |
moderation-checkuser
|
Peut voir les adresses IP des utilisateurs enregistrés sur Special:Moderation. | checkuser |
Conseils supplémentaires contre le vandalisme
Afin de prévenir le vandalisme, les mesures supplémentaires suivantes doivent être appliquées :
- Veuillez restreindre le renommage des pages à un groupe de confiance (et pas simplement aux « automodérés »), parce qu'il peut être utilisé pour le vandalisme difficile à annuler.
$wgGroupPermissions['automoderated']['skip-move-moderation'] = false;
$wgGroupPermissions['sysop']['skip-move-moderation'] = true;
- 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 la trace des nouveaux utilisateurs de la liste des ModificationsRécentes :
$wgLogRestrictions["newusers"] = 'moderation';
Utilisation recommandée / bonnes pratiques
Les bonnes pratiques suivantes sont recommandées :
- Seul le vandalisme doit être rejeté. Il est préférable que les modifications pauvres mais avec de bonnes intentions (par exemple, l'ajout de détails excessifs sur l'intrigue dans l'article du wiki sur un film) soient d'abord approuvées puis annulées comme d'habitude, et avec un motif dans le résumé de la modification. De cette façon, l'auteur n'est pas offensé et le texte est sauvegardé dans l'historique des pages, et visible par chacun pour des raisons de transparence et la responsabilité du contributeur.
- Tout utilisateur jugé légitime (qui a fait N bonnes modifications) doit être ajouté au groupe
automoderated. - Ajouter des utilisateurs au groupe
automoderatedvia$wgAutopromoteN'est PAS recommandé, car cela motive les vandales à faire de nombreuses modifications très mineures (par exemple, ajouter des liens interwiki). Il est mieux de les promouvoir àautomoderatedmanuellement pour une bonne contribution et non pas pour 30 modifications minables dont le but est simplement de faire grimper le compteur. - Abstenez-vous d'utiliser les blocages. Ne protégez pas les pages "juste au cas où", sauf peut-être pour les modèles importants.
- Permettez la réhabilitation complète des utilisateurs ayant un mauvais historique d'édition. Leurs modifications utiles aux articles doivent ê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 doivent être rejetés, de même que les éditions volontairement de mauvaise qualité.
- Notez aussi qu'un contributeur qui semble réinjecter une modification refusée ne signifie pas forcément qu'il entre en rebellion, mais qu'il a dû faire ses modifications sans avoir vérifié qu'elles avaient déjà été refusées entre temps.
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 :
- Ne pas approuver les modifications tant qu'elles ne répondent pas aux normes de qualité strictes de l'industrie.
- Ne pas 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 :
- Une nouvelle page apparaît comme un document entièrement revu, correctement formaté, sans coquilles, etc.
- Personne à part l'auteur et les modérateurs ne verrait les révisions imparfaites.
Inconvénients :
- 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 qu'il existe.
- Les modifications en attente n'ont pas d' « historique de modification ». La Modération ne stocke qu'une modification en attente pour chaque paire de 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'on suit 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.
Why not recommended? Answer: when following Best Practices, you would never Reject a good change just because it is formatted poorly. Whether this edit is good or not, you know from "diff" link. "Preview" link tells you "how is this page formatted", which shouldn't affect your decision.
- $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. Le 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.
Why not recommended? Answer: easy to mess up. Moderator can accidentally delete the text of pending edit (and it won't be recoverable). Furthermore, these changes are not attributed to moderator (after approval, it looks as if the original author made the edit this way), which is creepy.
Allowing moderators to mark users as automoderated
By default, any sysop can add users to automoderated and moderator groups.
If you want to allow moderators to mark users as automoderated, you can use the following configuration:
$wgAddGroups['moderator'][] = 'automoderated';
$wgRemoveGroups['moderator'][] = 'automoderated';
Compatibilité avec les autres extensions
- Extension:Moderation doit être la dernière activée dans LocalSettings.php, car elle fait échouer au moins l'accroche PageContentSave.
- Extension:Moderation prend entièrement en charge Extension:CheckUser, ce qui signifie que si l'extension CheckUser est activée, alors toute modification approuvée aura l'adresse IP correcte, l'agent utilisateur et XFF corrects enregistrés dans les tables checkuser.
- Extension:Moderation est entièrement compatible avec Extension:VisualEditor et Extension:MobileFrontend. Théoriquement, il devrait également fonctionner avec d'autres éditeurs basés sur API.
- 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.
- La modération des forums Flow doit être implémentée dans Extension:StructuredDiscussions. Ces forums utilisent un « modèle de contenu » non textuel, qui n'est pas pris en charge par Moderation.
- CommentStreams extension misinterprets "edit was queued for moderation" as an error, which can only be fixed in Extension:CommentStreams itself.
- Les extensions qui modifient plusieurs positions 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
- Extension:ConfirmEdit - extension commune CAPTCHA.
- Extension:AbuseFilter - extension commune contre les robots de pourriels et le vandalisme typique comme l'effacement.
- Extension:Approved Revs - permet de marquer une révision « approuvée » , étant la seule affichée par défaut sur une page.
- Extension:FlaggedRevs - version plus avancée (et lourde) de Extension:Approved Revs.
| Cette extension est incluse dans les fermes de wikis ou les hôtes suivants et / ou les paquets : Cette liste ne fait pas autorité. Certaines fermes de wikis ou hôtes et / ou paquets peuvent contenir cette extension même s'ils ne sont pas listés ici. Vérifiez toujours cela avec votre ferme de wikis ou votre hôte ou votre paquet avant de confirmer. |