Extension:Moderation/de

Die Erweiterung Moderation bietet Schutz vor Vandalismus für kleine und mittlere Wikis.

Dies ist eine der wirksamsten Methoden zum Schutz vor Vandalismus und hat nur sehr geringe Auswirkungen auf legitime Nutzer.

Einführung

 * Wie funktioniert es?:
 * 1) Jede Bearbeitung (oder jeder Bild-Upload) durch einen neuen Benutzer wird an eine Moderationswarteschlange gesendet.
 * 2) Bis der Moderator diese Änderung genehmigt hat, ist die Seite unverändert. Ausstehende Bearbeitungen werden weder im Seitenverlauf noch in den letzten Änderungen angezeigt.
 * 3) Der Benutzer kann seine Bearbeitung sehen und seine eigene Version der Seite weiter bearbeiten.


 * Wie moderieren die Administratoren?:
 * 1) Es wird eine neue Spezialseite eingerichtet (Spezial:Moderation). Sie ähnelt der Funktion "Letzte Änderungen", hat aber die Schaltflächen "Genehmigen", "Ablehnen", "Alle genehmigen" und "Alle ablehnen".
 * 2) Abgelehnte Bearbeitungen werden in das Archiv für abgelehnte Bearbeitungen aufgenommen.
 * 3) Genehmigte Bearbeitungen werden normal angewendet.
 * 4) Es werden Protokolle darüber geführt, "wer was genehmigt hat". Nur die Moderatoren können sie sehen.
 * 5) Wenn ein Bearbeitungskonflikt erkannt wird und nicht automatisch gelöst werden kann, hat der Moderator eine Schaltfläche zum Zusammenführen, um die Bearbeitung manuell zu übernehmen.


 * Warum ist es gut?:
 * 1) Neue Nutzer werden nicht durch lästige, Telefonnummernüberprüfungen usw. abgeschreckt. Sie bearbeiten normal, wie sie es in MediaWiki ohne Moderation tun würden.
 * 2) Sperren werden praktisch obsolet. Und Blockierungen sind nicht gut (man bedenke die Möglichkeit, einen legitimen Benutzer mit einer Bereichssperre zu treffen, oder die Unfähigkeit, gute Bearbeitungen von einem nicht sehr geeigneten Benutzer zuzulassen, der manchmal den Drang hat, eine oder zwei Seiten zu vandalieren).
 * 3) Vandalismus aus dem Wunsch heraus, "bemerkt zu werden", wird nicht geduldet. Niemand würde 5 Stunden lang nach neuen und neuen Proxys suchen, um den Administrator zu ärgern, wenn bekannt ist, dass all diese Aktionen kein Problem darstellen.
 * 4) Vandalismus-Methoden wie "eine Seite von zwei Konten aus vandalieren, um einen Ein-Klick-Rollback zu verhindern" sind nicht mehr wirksam.
 * 5) Die Website kann in anonymen Netzwerken wie TOR oder I2P betrieben werden.
 * 6) Users can hide their mistakes from appearing in the revision history and even from moderators by fixing them in time.

Alternativen
Verfügt MediaWiki über andere Methoden zur Bekämpfung von Vandalismus? Kurz gesagt - nicht wirklich.

MediaWiki wurde für Wikipedia entwickelt. Bei Wikipedia gibt es jederzeit Hunderte von Freiwilligen, die bereit sind, Vandalismus in Echtzeit zu bekämpfen. Fast alle anderen Wikis außer Wikipedia haben diesen Vorteil nicht. Die in MediaWiki eingebaute Idee, Vandalismus zu bekämpfen, besteht darin, dass Vandalismus mehr Zeit in Anspruch nimmt, als ihn rückgängig zu machen. Normalerweise ist das richtig, aber so wird Vandalismus nur unzureichend unterbunden, und die Administratoren müssen trotzdem häufig nach Vandalismus suchen, auch wenn das Zurücksetzen selbst nicht viel Zeit in Anspruch nimmt.

Es gibt drei bekannte Methoden zur Bekämpfung von Vandalismus:

In non-democratic countries editing a page on politics can result in government trying to identify and persecute the user. For example, Lurkmore.to was contacted by Russian "anti-extremist special force" with demands to disclose information about the authors of pages about Ramzan Kadyrov and Molotov cocktail. For example, a user can create 100 pages with offensive titles, but they can all be deleted by two clicks in. Moderation extension belongs to this category.
 * 1) Alle Änderungen schwer machen. Bei Lurkmore.to beispielsweise werden alle Änderungen von neuen Nutzern mit einem strengen Captcha versehen, und es sind viele Änderungen erforderlich, bis man endlich ohne das Captcha arbeiten kann. Daher muss der Vandale viel Zeit aufwenden, um eine Handvoll von Änderungen vorzunehmen.
 * Der offensichtliche Nachteil ist, dass alle legitimen Nutzer das Captcha ebenfalls passieren müssen, was kleinere Änderungen wie Rechtschreibkorrekturen abschrecken könnte.
 * 1) Benutzeridentifizierung erzwingen - zum Beispiel Anmeldung über Facebook. If the social network verifies that all its users have a valid mobile phone number, then each vandalism attempt requires the vandal to go to the shop and buy a new SIM card. This method is extremely effective, though eliminates the anonymous editing and turns away the users who don't have an account in any supported social network.
 * A strong minus of this method is the impact on users' privacy.
 * 1) Mitigate the results of vandalism.

Is this extension stable?
This extension is stable. It has been deployed in production on Russian Uncyclopedia (absurdopedia.net) since November 2014.

The extension has an automated testsuite with significant coverage (phpunit and Selenium). Every change to Moderation is automatically tested on:


 * 1) newest version of MediaWiki
 * 1) MediaWiki 1.35 (LTS)
 * 2) MediaWiki 1.31 ( legacy LTS )

Please read the files KNOWN_LIMITATIONS, TODO and WONT_DO for all known issues. Feel free to contact the author if you have any questions.

What's the difference from FlaggedRevs or Approved Revs?
and hide the bad revisions only from readers. The vandal edits will still exist in history and RecentChanges, and all editors will stumble upon them when they try to edit the page which was vandalized. Therefore editors would have to revert vandalism quickly.

On the other hand, Moderation completely eliminates vandal edits: non-approved revisions are simply not created in page history, etc. This ensures that not only readers, but also other editors won't see the vandal edits in any of the pages.

In short, (1) FlaggedRevs is for quality control but doesn't help against persistent vandalism. (2) Moderation is specifically against vandalism and renders it completely ineffective.

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

Installation for older versions of MediaWiki
For MediaWiki 1.31-1.34, replace the above-mentioned "git clone" command with the following:

For MediaWiki 1.27-1.30, replace the above-mentioned "git clone" command with the following:

For MediaWiki 1.23-1.26, replace the above-mentioned "git clone" command with the following:

These versions may still receive security fixes (if any), but not new features.

Parameters for LocalSettings.php

 * $wgModerationEnable: If set to false, then new edits are applied as usual (not sent to moderation). Default: true.
 * $wgModerationTimeToOverrideRejection: Time (in seconds) after which rejected edit could no longer be approved. Default: 2 weeks. Note: old rejected edits are NOT deleted (moderators can always look at them in Rejected folder even if this time has elapsed).
 * $wgModerationOnlyInNamespaces: If set to an array of namespace numbers (e.g. ), moderation is only enabled in these namespaces (edits in other namespaces will bypass moderation). Default (empty array): moderation is enabled everywhere.
 * $wgModerationIgnoredInNamespaces: If set to an array of namespace numbers (e.g. ), non-automoderated users can bypass moderation in these namespaces. Default (empty array): moderation can't be bypassed anywhere.
 * $wgModerationNotificationEnable: If true, notification email will be sent to $wgModerationEmail each time an edit is queued for moderation. Default: false.
 * $wgModerationNotificationNewOnly: If true, only notify about new pages (but not about edits in existing pages). Default: false.

See also: #Configuration options ONLY for pre-publish review (options not recommended for 95% of wikis).

Additional anti-vandalism tips
In order to prevent vandalism, the following additional measures should be applied:


 * 1) Please restrict the renaming of pages to a trusted group (not just "automoderated"), because it can be used for difficult-to-revert vandalism.
 * 1) Registering new accounts with offensive names is still a way for a vandal to show itself in the RecentChanges. A simple solution is to remove newusers log from RecentChanges:

Recommended use / good practices
The following good-practices are advised:

Not-so-good edits with good intentions (e.g. adding excessive plot details into the Wikipedia article about film) are better made Approved and then reverted as usual. This way the author is not offended and the text is saved in page history, viewable by anyone. Better promote them to  manually for one good edit and not promote for 30 useless-edits-made-for-count. Don't "just in case", except maybe for important templates. Their useful edits to the articles should be allowed, no matter how many times they were blocked. At the same time, trolling on talk pages should be rejected, so are the purposely-low-quality edits.
 * 1) Only vandalism should be Rejected.
 * 1) Any user that is deemed legitimate (does N good edits) should be added into   group.
 * 1) Adding users to   group via  is NOT recommended, as it motivates the vandals to do many very-minor edits (e.g. adding interwiki).
 * 1) Abstain from using.
 * 1) Allow the full rehabilitation of users with a bad history of editing.
 * 1) Please note that an editor who appears to be resubmitting a rejected edit does not necessarily imply an intent to edit-war, but the editor might have made changes to their pending edit without noticing that it was rejected in the meantime.

Non-recommended use: Moderation as pre-publish review extension
Moderation is an anti-vandalism tool first, but some wikis use it for quality control. For example, a wiki of scientific works might choose to:


 * 1) Not Approve any edits until they meet the strict quality standards of the industry.
 * 1) Not Reject any edits that are not yet good enough, so that the author could continue editing it as long as necessary.

Pros of this approach:


 * 1) New page appears as a fully reviewed, correctly formatted document with no typos, etc.
 * 1) No one except the author and moderators would see the imperfect revisions.

Cons:


 * 1) Other users can't improve the article until it is Approved. In fact, they won't even know that it exists.
 * 1) Pending changes don't have an "edit history". Moderation stores only 1 pending change for each Page/User pair. That's inconvenient if you are preparing your page for publication for weeks. User can even accidentally delete the necessary text in their pending revision, and it won't be recoverable.

Configuration options ONLY for pre-publish review
The following parameters are only needed when using Moderation for review. They are not recommended for 95% of wikis (when following the Best Practices, they are totally not needed).

''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.'' ''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.''
 * $wgModerationPreviewLink: If true, Preview link is shown on Special:Moderation. Default: false.
 * $wgModerationEnableEditChange: If true, moderators can modify the text of pending changes before Approving. Default: false.

Compatibility with other extensions
Theoretically it should also work with other API-based editors. (currently very few extensions do)
 * 1) Extension:Moderation should be enabled last in LocalSettings.php, because it aborts at least  hook.
 * 1) Extension:Moderation fully supports, meaning that if CheckUser extension is enabled, then any approved edit will have correct IP, user-agent and XFF saved in the checkuser tables.
 * 1) Extension:Moderation is fully compatible with  and.
 * 1)  (also known as Flow) and  will work, but edits in Flow/CommentStreams forums will bypass moderation.
 * Moderation of Flow forums should be implemented in Extension:StructuredDiscussions itself. These forums use a non-text "content model", which is not supported by Moderation.
 * CommentStreams extension misinterprets "edit was queued for moderation" as an error, which can only be fixed in Extension:CommentStreams itself.
 * 1) Extensions that modify several slots of Multi-Content Revisions (not just the main slot, as MediaWiki itself does) are not yet supported.

Siehe auch

 * - common CAPTCHA extension.
 * - common extension against spam bots and typical vandalism like blanking.
 * - allows marking a revision as "approved", being the one displayed by default on a page.
 * - more advanced (and heavy) version of.