Community health initiative/利用者ページ、名前空間、アップロードに対する部分ブロック

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Community health initiative/Partial blocks and the translation is 46% complete.

Outdated translations are marked like this.
Other languages:
Bahasa Indonesia • ‎English • ‎Nederlands • ‎dansk • ‎español • ‎français • ‎polski • ‎suomi • ‎العربية • ‎فارسی • ‎مصرى • ‎中文 • ‎日本語

Light-Bulb icon by Till Teenck green.svg

This page documents a feature the Wikimedia Foundation's Anti-Harassment Tools team has prioritized for software development.

🗣   We invite you to join the discussion!
🛠   Track in Phabricator at T2674.


このプロジェクトに関する協議はトークページTalk:Community health initiative/Per user page, namespace, and upload blockingで参加をお願いします。


Dof blocks f22.jpg



  1. 特定の1ページあるいは複数ページを対象とする編集
  2. 特定の1件あるいは複数の名前空間の全ページを対象とする編集
  3. ファイルのアップロード
  4. 自分以外の利用者へのメール送信



  • 全般に生産的な利用者が特定の話題に関してはこだわりがある(例=政治、宗教他)
  • 識別可能なIP帯域から長引く不正行為が行われる(例=あるスポーツチームの学生が対抗チームに関するページに不正行為を働く)
  • 2人かそれ以上の利用者が特定の相手と絡む編集を禁止する制裁(interaction ban)を受けている
  • 著作権のある画像を繰り返し投稿する特定の利用者
  • オンウィキでは全般的に生産的なのに、ウィキメール機能を不正利用する利用者
  • テンプレートに軽率な編集を行う利用者



  • 管理者が設定する。
  • 利用者名、IPアドレス、IPアドレス範囲を対象とする
  • 標準のブロック変数を備える: 理由、期限、トークページとサブページを対象にするかしないか、オプションとしてIPアドレスの自動ブロック。
  • ブロックログ、「特別:ブロック一覧」他、投稿ブロックを表示するページに掲出する。
  • ブロックされた利用者には、ブロックメッセージが表示され、ブロックの情報(ブロック処理をした管理者名、期限、理由、解除を依頼する方法)に加え、編集が禁止された対象が示されます。
  • 一度に設定できる投稿ブロックは1件とし、管理者がブロックした範囲により既設のブロックが変更されます。


March 13

Partial Blocks are now live on Arabic Wikipedia, which means they fully support non-Latin languages and RTL languages. Partial blocks is ready to enable on any language Wikimedia wiki (except Wikidata.) 🎇

We're looking for users who want to represent their wiki to enable this feature. Please leave a message on the talk page if you would like to help. Thank you!

February 13

Namespace blocks are live! 🚀

There are some minor fixes and changes we'll be working on over the next few weeks, but the next major stage for this project is to release to more wikis so we can observe how effective they are at mitigating user misconduct, and to get feedback about any changes we should make. Specifically, we are seeking to understand:

  1. What is an appropriate limit of the number of pages a user should be blocked from? In the first version limit is 10, but it can any number.
  2. How should partial blocks be logged to allow for accurate and specific logging while keeping the logs easy to read? Currently they are being logged comprehensively in the block log.
  3. Should a notice appear when someone edits the user or user talk page of a partially blocked user? Currently, a notice only appears if the user cannot edit that page (e.g. a user is blocked from their own user page)
  4. What features are missing that need to be built?

If you would like to have this functionality on your wiki to combat harassment, vandalism, or other forms of user misconduct, please let us know on the talk page.

January 30

As upload blocks will require additional database changes (which requires months of advance notice and planning) we will first complete page and namespace blocks before deciding to pursue upload blocks.

January 16, 2019

A screenshot of the MediaWiki interface for blocking users, taken January 14, 2019.

Today we reached another significant milestone! Partial Blocks have been enabled on Italian Wikipedia and the local wiki administrators are setting partial blocks to combat vandals! A big congratulation to my team for working through the inner guts of MediaWiki and all its processes to make sure we have a safe and reliable blocking tool. 🎉

If you would like to test the functionality, it will forever be available on (write us if you need admin privileges.) We're already talking to two other languages of Wikipedias about being testers — if your wiki would like to test please write on our talk page!

December 20

As 2018 draws to a close, our team is putting the final touches on Namespace blocks. This functionality should be ready in January on Test Wikipedia and on the non-English Wikipedias that are eager to adopt this new functionality. Our plan for early 2019 is to release to several wikis and make changes based on what problems and opportunities arise. We'll also build the ability to block a user from uploading files, creating new pages, and renaming pages.

Meanwhile, our team's analyst is analyzing data on the effectiveness of blocks. These measurements should help us better understand how many blocks are effective at stopping continued abuse to the wiki or its community members. We expect this data to show us if partial blocks are as effective as sitewide blocks and hope this data can inform the governance policies for when to levy blocks and block lengths.

December 5

Our team is still working on addressing the final defects before we enable Partial Blocks on Italian Wikipedia. We're optimistic that we can hit this milestone next week! In the meantime testing is still available on Test Wikipedia and Test Wikidata for users interested in taking a look at what's ready so far.

We're also confident that we can get Namespace blocks to a near-ready state by the end of December, before we break for the winter holidays. That functionality should be ready on Test Wiki in January.

November 26

We have a handful of bugfixes and feature enhancements to release this week! This list explains everything that's changed. In short, these changes will make Partial Blocks only affect exactly what is listed in the block set by the admin, as we originally intended. All changes will be available on by Wednesday of this week.

With this set of changed we feel confident in the stability and functionality of the feature. We are working with Italian Wikipedia to look-over the functionality on Test Wiki before they adopt the feature and integrate it into their user mediation workflows. If any other wikis are excited to use this functionality, please let us know and we'll begin working with you!

Meanwhile, our devs are also working on implementing Namespace blocks. We hope to have them completed in the coming weeks.

November 8

Partial blocks are live on Test Wikipedia and Test Wikidata! If you're an admin on another wiki and would like to test the functionality please write a message on our talk page.

This first feature set is limited: admins can block an user or IP from editing up to 10 specified pages. There are some known defects that we're currently working on (for example, if an admin is partially blocked from a page they can't delete any page.) and we'll get back to building namespace and upload blocks in later November.

If you're testing partial blocks we'd love to hear from you! Drop us a note about your experience with the tool. We're looking specifically for feedback about:

  • What is an appropriate limit of the number of pages a user should be blocked from? In the first version limit is 10, but it can any number.
  • Are you satisfied with how partial blocks are logged?
  • Do we need to change anything that has already been built?
  • Is the warning message in the VisualEditor too gentle?

Thank you!

October 19

We're making significant progress on Partial Blocks and are nearly live on production wikis. We hope to have a functional version on and in the coming weeks. We're very excited to share it with you!

While the devs put the final touches on the first version, others on our team are currently thinking about how we want to measure the effectiveness of blocks. We're asking ourselves (and anyone who will listen) questions like "Are blocks effective at stopping harm? Do users who are blocked return to make constructive edits? How do we measure this?" — if you are interested in discussing this topic, we have a 7 proposed measurements and commentary on why we selected them at the other project page.

As part of this, we've generated some data on how frequently blocks are set (did you know there are currently 3.4 million active blocks?) and pages are protected (~20,000 pages are currently protected) to better understand the scale of administrative actions.

September 24

We have a fourth round of designs, based on feedback from our second round in June. Here are the two new designs, detailed UI element views can be seen in the gallery below. in #Designs

September 21

Our team is nearly ready to release the first feature set of partial blocks — the ability to block a user from ≤10 pages — on the beta environment then test.wikipedia by mid-October. We are talking with some early opt-in wikis to test the functionality, please let us know if your wiki would be interested in utilizing this functionality, which also gives you a great opportunity to dictate the future of this project!

In other news, due to technical complexity, we have decided to de-prioritize multiple blocks (phab:T194697) and remove it from this project. I've moved the documentation here. This small amount of functionality would take a very large amount of time to build and we first want to make sure page, namespace, and upload blocking work as expected and actually produce meaningful impact. We'll have another round of designs soon and we look forward to delivering a great partial blocks feature in the coming months!

September 4

We have our third round of designs almost ready and we want to share them now before we go too far without validating our direction. These designs include functionality to view details about multi-blocks. Because of this change we need to introduce a new piece of information during the blocking process. This led us to the idea of a block modal window, which can theoretically appear on any page — a diff page, recent changes, a profile, etc. This would allow an admin to block a user without having to navigate to another page. Here is how it would work:

// designs redacted, moved here. //

August 22

Based on conversations on the talk page, in person at Wikimania last month, and on the TechComm RFC for this project our team has decided to merge the project of multi-blocks into Partial Blocks. The goal of multi-blocks is to allow admins to set multiple concurrent blocks against an account with independent expiration dates, decreasing the manual workload on administrators. Example use cases for multi-blocks include:

  • User:Apples has been indefinitely blocked from editing Neptune. They then receive a 24 hour full-site block. When the full site block expires, they should continue to be blocked from Neptune.
  • User:Bananas is indefinitely blocked from editing Mars and from editing Venus until 2025. An admin wants to block them from Saturn for one month.
  • After User:Carrots has violated a wiki policy, an admin wants to set both an indefinite block against Pluto and a 24-hour sitewide block at the same time, without having to write a self-reminder to update the block.

This will require changes to Special:Block, Special:Unblock, Special:BlockList, and Special:Contributions. We are working on another round of designs (with minimal changes from the last round) which we will post on this page next week. Work for multi-blocks will be tracked in Phabricator at phab:T194697. Our TechComm RFC can be found at phab:T199917 which includes all our proposed database changes and other technical implementation details.

August 8

Most feedback we’re receiving at this stage in the project is about one hypothetical — yet entirely likely — workaround a malicious user could exploit to their advantage: a user using a temporary sitewide block to erase (and therefore evade) an indefinite partial block. This could be resolved with manual solutions (e.g. calendars and reminders to reinstate the partial block) but this is inconvenient and interruptive to your workflows and prone to human error. It’s clear that we need to determine a solution to prevent this abuse before Partial Blocks releases to most wikis. There are a few ways to do this and this can get pretty complicated, please help me determine which system we should build:

Option 1 - Re-blocks

Description: If an admin escalates a partial block to a sitewide block and the expiration date for the sitewide block is shorter than the previous partial block, the admin should have an option for the block to revert to the previous partial block parameters when the sitewide block expires.

Example: An admin blocks User:Apples from editing the page Argentina for 9 months. The same day, an admin modifies the block to Argentina and Bahamas for 8 months. The same day an admin blocks the user from the entire site for 7 months. After 7 months, User:Apples would be blocked from Argentina and Bahamas for 1 more month, after which the partial block would be entirely expired.

This change would only require adding one additional option into the Special:Block UI when a block is being modified.

Option 2 - Multi-blocks

Description: Admins should be able to set different expirations for different elements of a block.

Example: An admin could block User:Bananas from editing Argon for 9 months, Boron for 8 months, and sitewide for 7 months. After 7 months, the user would be blocked from Argon and Boron and after 1 more month the user would be blocked only from Argon. After 1 more month the partial block would be entirely expired.

This change would require a more significant change to how blocks are currently logged and managed on Special:Block, Special:BlockList, Special:Contributions, and Special:Unblock. Users can be partially blocked from an unlimited number of pages, meaning every page could hypothetically have a different expiration, which could lead to some complicated situations.

Option 3 - Something else!

We’d love to hear more alternate proposals. Please discuss on the talk page.

For all options it should be possible for an admin to clear all blocks from an account, leaving it entirely unblocked. This will most likely be a change to Special:Unblock.

Join us on the talk page to let us know what you think!














初期のモックアップでは「ファイルのアップロード」と「ページの移動」を有効にしていない状態を表示しています。 このエラーは設計の次の段階で修正します。

  • 図の「Reason」(訳注:理由)のドロップダウンは幅が可変で、それぞれのウィキ固有のリストに合わせて幅を最大まで広げて表示します。現状と同じ機能をします。
  • ブロック履歴テーブルの読み込みにajaxを追加する予定です。小さなモニタではツールの下に、また横長のモニタでは、左書き(書記方向が左から右)のウィキの場合はツールの右側に表示します。



  • この機能は既存の「特別ページ:ブロックされている利用者」と心理的なモデルやワークフロー、ユーザー体験がほぼ同じことから、この機能を新しいツールとしてではなく現状のツールに追加して組み込むと最も論理的で実用的だと考えています。ブロックの大半はサイト全体にわたると解釈され、今後も既定のワークフローも現在の使用法と共存するように最適化していきます。変更点はすべて、既存の機能への追加として扱います。
  • カテゴリ別のブロックは、複雑な課題があることから保留にしました。ページや名前空間、アップロードのブロックが必ず十分に機能するように図ります。その目的とは、コミュニティが適した制裁を設定でき、困った存在の利用者に生産的な活動をしてもらいつつ、問題を起こしがちな領域から遠ざけることです。
  • このプロジェクト全体の中断が提案されています。私たち嫌がらせ対策ツールチームでは、これが状況に対処する有用なツールになると強く信じており、また同時に、制裁の仕方を変えてしまうため、これをウィキに実装するには繊細さが必要だと認識しています。部分ブロックがすべての状況に適しているとは信じていませんし、依然として状況によって社会的に制裁を強制する必要があるかもしれません。


  • 「特別:投稿ブロック」にラジオボタンを追加して、サイト全体ブロックか部分ブロックかを選択します。
  • サイト全体 sitewide を選択してブロックを保存すると、ブロックは現状と同じ挙動を示します。
  • 部分ブロック partial を選択した場合、管理者にはページおよび/または名前空間の一覧が表示されます。
    • 管理者がページをブロック指定する場合:
      • ページブロックは、現在存在するページにのみ設定でき、入力フィールドで妥当性確認(validation)が求められます。
      • 管理者は自動提示機能を使うと、適したページを見つけやすくなります。
      • 対象とするページは、任意の名前空間から選べます。
      • ページが移動または削除されても、利用者は当該のページの編集ブロックを受け続けます(つまりページ名ではなくページIDでブロックする)。
    • 管理者が名前空間をブロック指定する場合:
      • 入力フィールドは、有効な名前空間名に限って受けつけし、入力フィールドで妥当性の検証(validation)が求められます。
      • 利用者は自動提示機能を使うと、正しい名前空間を見つけやすくなります。
  • 新しい入力フィールドにはヘルプのツールチップを用意します。
  • 「特別:投稿記録」、「特別:投稿ブロック」、「特別:ログ」におけるブロックログ記録は、部分ブロックかどうか表示します。
    • サイト全体ブロックのログ記録は変更しません。
    • ページをブロックすると、ログ記録にタイムスタンプにブロック管理者 (t|c|b) が BadApples (t|c) の Foobar ページ編集を期限 N までブロックしました (理由) (ブロック解除 | ブロック変更)を表示します。
    • 名前空間をブロックすると、ログ記録にタイムスタンプにブロック管理者 (t|c|b) が BadApples (t|c) の Foobar ページ編集を期限 N までブロックしました (理由) (ブロック解除 | ブロック変更)を表示します。
    • ページと名前空間の両方をブロックすると、ログ記録にタイムスタンプにブロック管理者 (t|c|b) が BadApples (t|c) の Foobar ページとFoobar2 名前空間の編集を期限 N までブロックしました (理由) (ブロック解除 | ブロック変更)を表示します。
  • 設計ではブロック情報は「特別ページ:ブロックされている利用者」で管理し注釈を付けます
  • 利用者が条件に該当するページを編集しようとすると、新しいストリングキーを使ってブロックの内容(理由、期限他)を通告する新種のブロック警告メッセージが表示されます。
  • 利用者が受けるブロックは1回に1件に限定され(現状と同じ) — 管理者がブロックを変更しない限りブロックは更新されません。
  • 部分ブロックが設定されると、ブロック期限まで、この利用者が自分のトークページを編集できなくするのチェックボックスが無効になります。
  • ブロック API は、部分ブロックの機能すべてをサポートするように更新する必要があります
    • API を利用したサイト全体のブロック設定は変わりません
    • API 説明文書を更新します
    • API を利用した部分ブロック設定は、適合しないページや名前空間を対象外にします





  • カテゴリが、該当する記事ページのトークページを示す可能性がある場合はどう処理するか?
  • カテゴリーブロックの範囲は、サブカテゴリの深さで何層目まで適用するか?
  • 自分のブロックを回避してソックパペットを使用し、ページからカテゴリを削除する利用者への対処はどうすればよいか?
  • これ(カテゴリブロック)を実施すると、ユーザーとして処理速度低下に影響するかどうか?





この作業をより正確に効率化するツールの実装については、編集制限ページ Editing restriction page でアイデアの提案や共有をしています。編集制限のトークページTalk:/Editing restrictionsでは、現在、直面している問題と、技術的な解決策でどう対処するか議論する参加者を募集しています。