Extension:Moderation
調整拡張機能は小規模から中規模のウィキ向けに荒らし対策を提供します。
これは荒らし対策の保護処理として最強の手段のひとつであり、正当な利用者に対する影響は非常に小さいものです。
 警告: | This extension is currently incompatible with temporary accounts. |
はじめに
- 動作の仕組みは？
- 新規利用者の編集 (もしくは画像投稿) はすべて調整キューへ送ります。
- 調整役の承認を得るまで、それらのページに修正は反映されません。承認待ちの編集はページの履歴にも最近の更新にも表示されません。
- 投稿した利用者には自分の編集内容が表示され、当該ページの編集を非公開で続けることができます。
- 管理者の調整の手順は？
- 新規に特別ページが提示されます (Special:Moderation)。 最近の更新にやや似ていますがボタンが固有で、「承認」「却下」「すべて承認」「すべて却下」("Approve", "Reject", "Approve all" and "Reject all") と揃っています。
- 却下した編集は専用のアーカイブに移されます。
- 承認された編集は通常のとおり、ページに反映します。
- 「誰が何を承認したか」の記録が保守されます。閲覧できるのは調整者に限定されます。
- 編集の競合が検出され自動的に解決できない場合は、調整者は統合ボタンを使い手動で編集を行います。
- 利点は？
- 新規利用者にいきなりcaptchasや電話番号認証その他を求めて萎縮させることがありません。 調整を受けない平常の状態で編集を継続できます。
- わざわざブロックを使わなくて済みます。. ブロックに良い効果はありません (範囲ブロックをかけると無関係な利用者を巻き込むこと、たまに気まぐれに1、2ページで不正行為をする程度の利用者から良質の編集をするチャンスを奪うことにもご配慮ください。)
- 「承認欲求」が原因の不正行為は慎むべきです。もしそういう行為は許されるという認識の結果であれば、5時間もかけて新しいプロキシを探し、管理者を怒らせようとする人などいません。
- 「複数のアカウントを使って特定のページを荒らし、ワンクリックで巻き戻せないようにする」方法の荒らしは、すでに無効です。
- ウェブサイトによっては匿名性の高いTORあるいは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.
代替策
MediaWikiが採用するその他の荒らし対策とは？ 一言でいうなら - ありません。
MediaWikiはウィキペディアのために創設されました。 ウィキペディアであれば、どんな時間帯でもリアルタイムに荒らしを巻き戻すために協力するボランティアが何百人、何千人といます。 ウィキペディア以外に、そのような恵まれた状況にあるウィキはほぼ皆無です。 MediaWikiで荒らし対策を常備しようと考えた背景は、そのほうが巻き戻しよりも作業時間を短縮できると考えたからです。 通常はこの考え方が適切ですが、これでは荒らしを未然に防ぐ効果は望めず、たとえ巻き戻し自体の作業時間は短くても、管理者がしばしば荒らされていないか確認する手間に変わりはありません。
現状では荒らし対策として次の3つの方法があります。
"すべての編集を難しくする" 一例としてLurkmore.toでは、新人利用者の編集に1件ずつ認証を受ける強力なキャプチャ方針を設けており、その手順を経ずに編集を認めるまで、多数の編集実績を求めています。 そのため、荒らしはほんの一握りの編集をするために多くの時間を費やさなければなりません。
- ただし、正規の利用者が CAPTCHA を回避しなければならないため、スペルチェックのような細かい編集ができなくなるというデメリットもあります。
- 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.
- 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]
- 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:Nuke. Moderation extension belongs to this category.
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:
- newest version of MediaWiki
- MediaWiki 1.35 (LTS)
- MediaWiki 1.31 (旧版 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.
| Moderation | FlaggedRevs/ApprovedRevs | |
|---|---|---|
| Do readers see vandalism? | いいえ | いいえ |
| Do editors see vandalism? | いいえ | はい |
| Does vandalism remain in page history? | いいえ | はい |
| Can quickly reject all edits by user? | はい | いいえ |
| Can other editors improve non‑approved edits? (not vandalism) | いいえ | はい |
インストール
For modern versions of MediaWiki (1.35+), use the following instruction:
- Check-out the sources with
git clone https://github.com/edwardspec/mediawiki-moderation.gitして、ファイルをextensions/フォルダー内のModerationという名前のディレクトリ内に配置します。 - 以下のコードを LocalSettings.php ファイルの末尾に追加します:
wfLoadExtension( 'Moderation' );
- 更新スクリプトを実行します。このスクリプトは、この拡張機能が必要とするデータベーステーブルを自動的に作成します。
完了 – ウィキの「Special:Version」に移動して、拡張機能が正しくインストールされたことを確認します。
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">
LocalSettings.php のパラメーター
- $wgModerationEnable
falseを設定すると、新規の編集は通常どおり反映されます (調整過程へ送付されない。) 既定の状態は次のとおりです。true.- $wgModerationTimeToOverrideRejection
- 却下された編集が承認されなくなる経過時間 (秒単位)。既定で 2週間 weeks。 注記：古い差し戻し編集は削除されません (調整者はこの期間終了後も「却下フォルダ」(Rejected) を開くと常時、閲覧できます。)
- $wgModerationOnlyInNamespaces
- もし一連の名前空間番号を指定した場合 (例
$wgModerationOnlyInNamespaces = [ NS_MAIN, NS_FILE ];)、調整の実行はその指定の名前空間のみを対象にします (他の名前空間における編集は調整処理をバイパス)。既定 (一連は空欄): 調整処理は場所を問わず実行可能です。 - $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:
| 権限 | 利用者ができることは？ | この権限は何？ (既定の場合) |
|---|---|---|
skip-moderation
|
編集は通常どおりに反映される。 (調整過程へ送付されない) | automoderated, sysop, bot |
skip-move-moderation
|
ページの移動は通常どおり実施される。(調整過程に送付されない) | automoderated, sysop, bot |
moderation
|
特別:調整 Special:Moderation を閲覧できる | moderator, sysop |
moderation-checkuser
|
特別:調整 で登録利用者の IP を閲覧できる。 | checkuser |
荒らし対策のその他のヒント
荒らし予防には、以下の方法も補足して採用するべきです。
- 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;
- 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';
推奨される使い方 / 最善の手法
次に挙げた最善手法をお勧めします。
- Only vandalism should be Rejected.
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.
- Any user that is deemed legitimate (does N good edits) should be added into
automoderatedgroup.
- Adding users to
automoderatedgroup via$wgAutopromoteis 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.
- Abstain from using blocks.
Don't protect pages "just in case", except maybe for important templates.
- 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.
- 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:
- Not Approve any edits until they meet the strict quality standards of the industry.
- 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:
- New page appears as a fully reviewed, correctly formatted document with no typos, etc.
- No one except the author and moderators would see the imperfect revisions.
Cons:
- Other users can't improve the article until it is Approved. In fact, they won't even know that it exists.
- 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';
他の拡張との連携
LocalSettings.phpにおいて、Extension:Moderation は一番最後に有効化するべきで、理由は少なくとも PageContentSave のフックを無効化するからです。- Extension:Moderation は Extension:CheckUser をフルにサポートし、つまりチェックユーザー拡張機能を有効にした場合、承認済みの編集であれば checkuser のテーブル群に保存された正しい IP、ユーザエージェント、XFF が反映されます。
- 調整拡張機能 Extension:Moderation は Extension:VisualEditor とも Extension:MobileFrontend とも完全に互換性があります。 理論上はその他の API-基準のエディタでも機能するはずです。
- Extension:StructuredDiscussions (別称フロー Flow) ならびに Extension:CommentStreams は機能しますが、Flow/CommentStreams フォーラムにおける編集は調整機能をバイパスします。
- Flow フォーラムの調整は Extension:StructuredDiscussions 事態で実行するべきです。これらのフォーラムは非文の "コンテンツモデル" を採用し、調整拡張機能では対応していません。
- CommentStreams extension misinterprets "edit was queued for moderation" as an error, which can only be fixed in Extension:CommentStreams itself.
- 拡張機能のうち複数スロットのマルチコンテンツ・リビジョン (Multi-Content Revisions) を変更する動作はまだサポートされていません (MediaWiki 本体はメインのスロット限定、複数スロット対応ではない) (現状で対応する拡張機能はとても少ない)
関連項目
- Extension:ConfirmEdit - よく使われる キャプチャ 拡張機能。
- Extension:AbuseFilter - よく使われる拡張機能で、スパムボットや白紙化などの荒らし行為に対応。
- Content approval extensions
| この拡張機能は以下のウィキ ファーム/ウィキ ホスト/パッケージに含まれています: これは正式な一覧ではありません。 一部のウィキ ファーム/ウィキ ホスト/パッケージは、ここに記載されていなくてもこの拡張機能を含んでいる場合があります。 必ずご利用のウィキ ファーム、ウィキ ホスト、バンドルで確認してください。 |