MediaWiki

Extension:Moderation

This page is a translated version of the page Extension:Moderation and the translation is 29% complete.
Outdated translations are marked like this.
Languages:
MediaWiki扩展手册
Moderation
发行状态： 稳定版
实现 特殊页面
描述 将新用户的所有编辑和上传发送到审核。
作者 Edward Chernenko
最新版本 1.7.9 (2024-01-13)
兼容性政策 master分支维持向后兼容。
MediaWiki 1.39+ (master branch)

1.35-1.38 (REL1_35 branch)
1.31-1.34 (REL1_31 branch)
1.27-1.30 (REL1_27 branch)

1.23-1.26 (REL1_23 branch)
PHP 7.0+
数据库更改 是
表 moderation
moderation_block
许可协议 GNU通用公眾授權條款3.0或更新版本
下載

GitHub:

参数

  • $wgModerationEnable
  • $wgModerationTimeToOverrideRejection
  • $wgModerationOnlyInNamespaces
  • $wgModerationIgnoredInNamespaces
  • $wgModerationNotificationEnable
  • $wgModerationEmail
  • $wgModerationNotificationNewOnly
添加权限

  • moderation
  • skip-moderation
  • skip-move-moderation
  • moderation-checkuser
使用的函数钩
提供的函数钩
翻译Moderation扩展

适度扩展可以提供对于中小型维基的破坏的保护措施。

这是最有效的反破坏方法，对正常用户有极小的影响。

警告 警告： This extension is currently incompatible with temporary accounts.

简介

它是如何工作的？
  1. 新用户的每次编辑（或图像上传）都被发送到审核队列。
  2. 在版主批准此编辑之前，页面不变。待处理的编辑既不在页面历史记录中，也不在最近更改中。
  3. 用户可以看见并修改自己的编辑版本。
版主如何审核编辑？
  1. 有一个新特殊页面，名为Special:Moderation 这很像最近更改，但是有接受、拒绝、全部接受、全部拒绝四个选项。
  2. 被拒绝的编辑被自动归档
  3. 被接受的编辑会被自动应用。
  4. 审核记录会被保存，仅版主可见。
  5. 如果发现编辑冲突，版主可以合并编辑。
优势
  1. 新用户不会因为人机验证 或手机验证而不愿意编辑。 他们将正常编辑，和没有Moderation扩展一样。
  2. 封禁将几乎无用 同时，封禁有以下问题：
  • 可能会因为段封禁印象正常用户
  • 有时可能会影响经验不足的用户
  1. Vandalism out of "wanting to be noticed" is discouraged. No one would sit for 5 hours looking for new and new proxies to make admin angry, if it's known that all those actions are not a problem.
  1. Vandalism methods like "vandalizing one page from two accounts to prevent one-click rollback" are no longer effective.
  1. Website can operate in anonymous networks like TOR or I2P.
  1. Users can hide their mistakes from appearing in the revision history and even from moderators by fixing them in time.
  2. Since any edit is only permanently recorded upon approval, users can correct botched edit summaries.

替代

 
审核日志

Does MediaWiki have other counter-vandalism methods? In brief - not really.

MediaWiki was developed for Wikipedia. At any given time, Wikipedia has hundreds of volunteers willing to revert vandalism in real time. Almost every other wiki besides Wikipedia doesn't have that kind of advantage. The built-in counter-vandalism idea of MediaWiki is that vandalism takes more time than reverting it. Normally that's true, but this does a poor job at discouraging vandalism, and the admins still have to check for vandalism often, even if the reverting itself doesn't take much of their time.

There are three known methods of fighting vandalism:

  1. Make all edits hard.

For example, Lurkmore.to imposes a strong captcha on all edits from new users, and it takes a lot of edits to finally be able to edit without the captcha. Therefore the vandal has to spend a lot of time to do a handful of edits.

  1. The obvious minus is that all legitimate users have to bypass the captcha as well, which could discourage minor edits like spelling fixes.
  1. Enforce user identification - for example, login via 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.

  1. A strong minus of this method is the impact on users' privacy.

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.[1]

  1. Mitigate the results of vandalism.

For example, a user can create 100 pages with offensive titles, but they can all be deleted by two clicks in Extension:大量删除 . Moderation extension belongs to this category.

这个扩展稳定么？

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?

Extension:FlaggedRevs and Extension:Approved Revs 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.

审核 FlaggedRevs/ApprovedRevs
读者是否看到破坏行为？ No No
编辑者是否看到破坏行为？ No 是
页面历史中是否存在破坏行为？ No 是
可以快速拒绝用户的所有编辑吗？ 是 No
其他编辑者可以改善未经批准的编辑吗？ （不是故意破坏） No 是

安裝

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

该扩展应该在所有其他设置和扩展名之后的“LocalSettings.php”文件中最后启用。

Installation for older versions of 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

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

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

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

配置

<span id="Parameters_for_LocalSettings.php ">

$LS的参数

  • $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. $wgModerationOnlyInNamespaces = [ NS_MAIN, NS_FILE ];), 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. $wgModerationIgnoredInNamespaces = [ NS_MAIN, NS_FILE ];), 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 (e.g. $wgModerationEmail = 'send.to.this.address@example.com';) 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).

Editing notices

When a user who is not in a trusted group edits a page, a message is added to the top of the page informing the user about moderation. You can edit this message by editing the MediaWiki:Moderation-edit-queued page.

用户权限

This extension adds two groups (automoderated and moderator), which have the following rights:

Right What can the user do? Who has this right? (by default)
skip-moderation Edits are applied as usual (not sent to moderation). automoderated, sysop, bot
skip-move-moderation Page moves are applied as usual (not sent to moderation). automoderated, sysop, bot
moderation Can access Special:Moderation moderator, sysop
moderation-checkuser Can see IPs of registered users on Special:Moderation. checkuser

其他防破坏提示

为了防止破坏，应采取以下附加措施：

  1. Please restrict the renaming of pages to a trusted group (not just automoderated), because it can be used for difficult-to-revert vandalism.
$wgGroupPermissions['automoderated']['skip-move-moderation'] = false;
$wgGroupPermissions['sysop']['skip-move-moderation'] = true;
  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: 
    $wgLogRestrictions["newusers"] = 'moderation';

推荐使用/良好做法

建议采取以下良好做法：

  1. 仅应拒绝破坏行为。 Not-so-good edits with good intentions (e.g. adding excessive plot details into the wiki's article about a movie) are better made Approved and then reverted as usual, and with a reason in the edit summary. This way the author is not offended and the text is saved in page history, viewable by anyone for transparency and editor accountability.
  1. Any user that is deemed legitimate (does N good edits) should be added into automoderated group.
  1. Adding users to automoderated group via $wgAutopromote is NOT recommended, as it motivates the vandals to do many very-minor edits (e.g. adding interwiki).

Better promote them to automoderated manually for one good edit and not promote for 30 useless-edits-made-for-count.

  1. Abstain from using blocks .

Don't protect pages "just in case", except maybe for important templates.

  1. Allow the full rehabilitation of users with a bad history of editing.

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. 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.

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).

  • $wgModerationPreviewLink
    If true, Preview link is shown on Special:Moderation. Default: false


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.

  • $wgModerationEnableEditChange
    If true, moderators can modify the text of pending changes before Approving. Default: false.


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';

Compatibility with other extensions

  1. Extension:Moderation should be enabled last in LocalSettings.php, because it aborts at least PageContentSave hook.
  1. Extension:Moderation fully supports Extension:用户查核 , 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 Extension:VisualEditor and Extension:移动版前端 .

Theoretically it should also work with other API-based editors.

  1. 扩展:结构式讨论 (also known as Flow) and Extension:CommentStreams will work, but edits in Flow/CommentStreams forums will bypass moderation.
  1. 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.
  1. 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.

(currently very few extensions do)

參見

Retrieved from "https://www.mediawiki.org/w/index.php?title=Extension:Moderation/zh&oldid=6851264"