Wikipedia:編集フィルター/提案

ここは、新しい編集フィルターの作成や、既存のフィルターの（大幅な）仕様変更について、議論したり提案したりするページです。

原則として、新しいフィルターはここで提案し合意形成の後に作成するようにしてください。 やむを得ず合意形成をすることが出来ないまま作成されたフィルターについても、その狙いなどを報告をするように努めてください。

提案と作成

フィルターを提案する前に

Wikipedia:編集フィルター/一覧を参照し、同じ機能のものが既にないか確認してください。

また、フィルターの機能について以下の点に留意してください。

• フィルターはすべての編集を対象とします。それゆえに、例えば、単一ページに加えられた問題のある編集への対処には、編集フィルターの利用は向かないでしょう。
• フィルターはどれも作動に時間をとるので、編集が（およびその他も多少）若干ながら遅くなります。一つのフィルターにつき数ミリ秒程度遅くなるだけですが、フィルターが増えれば合算でそこそこになりえます。
• フィルターがチェックできることには限界があります。もっと複雑で必要不可欠ではない機能（たとえば、ページ内容を掘り下げたチェックが必要な場合や、フィルターシステムでは取得できない情報を必要とする場合など）は、個人のコンピュータやツールサーバ上で別のソフトウェアを用いて行う方がよいでしょう。

新しく提案するには

新しい提案は「提案中のフィルター」の一番上に次の形式で追加してください。

=== フィルターの名前 ===
{{編集フィルター提案|提案中
|目的 = <!-- どんなページ、もしくはどんな利用者に、どんな働きをするフィルターか -->
|理由 = <!-- このフィルターが必要な理由 -->
}}
--~~~~ <!-- 署名を忘れずに！ -->

目的にはそのフィルターの動作仕様、理由にはその動作が必要な理由を書いてください。

具体的なフィルターの発動条件などの提案は歓迎されますが、フィルターの提案するにあたって絶対に必要ではありません。 特に、明確な悪意を持った荒らしに対処するようなフィルターなど、フィルターの詳細を非公開にすべきようなものの場合は、発動条件を詳細に明記し議論しない方が良い場合があるので、注意してください。

新しく提案したものは、テンプレート:編集フィルターの一覧へ載せることができます。

提案から正式稼動までの流れ

以下の手順は草案です。以下の手順に支障や問題、コメントがあればWikipedia‐ノート:編集フィルターで提起してください。

1. 新しく提案するにはの手順に従って、新しいフィルターがどんなものか提案してください。
2. その作成提案に対して、{{賛成}}や{{反対}}、{{コメント}}、{{問}}などを使って議論し、作成することに対する合意形成をしてください。
   • もし、提案後1週間が経過し、2人以上の賛成（提案者の提案者票を含めても良い）があり、かつ反対する人がいない場合は、合意がなされたとみなされます。
3. 合意形成がなされたフィルターは、編集フィルター編集者によって新しく作成され、1週間の発動条件の試験と、1週間の対処操作の試験の、合計2週間の試験運用を行ないます。
   • 作成は、フィルター編集者であれば誰でもすることができ、自分が提案したフィルターの作成も可能です。
   • フィルターの提案は、試験中のフィルターに移動されます。移動した場合、{{編集フィルター提案}}を「試験中」とし、作成したフィルターの番号を示してください。
4. 前半の1週間は、発動条件の確認をするための試験が行なわれます。この期間中は、対処操作（ただし、速度制限は発動条件とみなされます）を設定できません。
5. 前半の試験期間が問題なく経過すれば、対処操作が付与され、後半の1週間は、対処操作の試験となります。
   • 各期間中に問題が発生したあるいは報告された場合は、修正を行ない、期間は修正からさらに1週間延長されます（つまり、修正が加えられると期間はリセットされます）。ただし、反応速度の向上などの微修正の場合は延長する必要はありません。
6. 対処操作の試験期間が問題なく経過すれば、試験運用は終了し、フィルターは正式稼働となり、情報はWikipedia:編集フィルター/一覧に過去ログ化されます。
   • 正式稼動後に問題が発生した場合は、Wikipedia:編集フィルター/誤作動で報告してください。

非公開フィルターに関する注意

非公開フィルターの作成を提案し議論する場合は、そのフィルターが非公開になる理由によく注意して、慎重に議論あるいは情報提供を行なってください。

特に、明確な悪意を持った荒らしに対処するようなフィルターなどの場合、詳細な発動条件などに関して公開の場で議論を行なうと、そのフィルターの有用性が低下するばかりか、かえって悪用される可能性もあります。

そのフィルターが、本当に非公開にしなければならないような深刻な問題に対するものなのであれば、あなたが詳細を述べなくとも編集フィルター編集者はその意図を十分に汲みとってフィルターを作成してくれるでしょう。

既存フィルターの仕様変更

新しく作成するのではなく、既存のフィルターの動作を大きく変えるような変更、つまり、

• 対処操作の付与と除去
• 通知文の（大幅な）内容の変更
• フィルターの発動対象の操作（発動条件のねらい）の変更

といった、誤作動や誤りなどの訂正でない変更の提案は、仕様変更提案で扱われます。

ログ化

正式稼動もしくはフィルターの作成が合意できなかった提案は、1週間ののち過去ログ化されます。

仕様変更提案は、各フィルターのページに過去ログ化されます。

Wikipedia:編集フィルター/提案/ログをご覧ください。

提案中のフィルター

白紙化/除去対策

提案中

目的	単純な荒らし対策
理由	ここ数日、ISECHIKAによる大量の白紙化荒らし（例えばこの履歴に複数、利用者名が不可視化されたものがあるのがお分かりいただけると思います）や、それに限らず対話などに全く応じず、ブロックされるまで延々と、すごい勢いで荒らし続ける単純な荒らしの足止めを狙っています。
発動条件	編集回数50回未満の利用者が、30分以内に10回以上、-1000以上の編集を行ったとき
コード	edit_delta <= -1000 & user_editcount < 50（と30分以内に10回以上）
対処操作	不許可

延々と荒らし/リバートが続くのを減らすのが目的です。巻き添えを減らしつつ荒らしの邪魔ができるラインを考えてみました（善良な利用者が30分以内に10回も大量除去するのは考えにくい）。一応バイト数だけを持って荒らしと断定することはできないので、連続投稿はお控えくださいのような案内文にすれば良いかと思います。--Q8j（会話） 2020年7月25日 (土) 10:31 (UTC)コードミス訂正--Q8j（会話） 2020年7月26日 (日) 14:51 (UTC)

コメント 特定のLTA狙い撃ちの対策に詳しくないので賛否は控えますが、緊急的な荒らし対策なら、非公開で作った後に、詳細は伏せて作成の追認を投げておくのが良いと思います。基準値も試験フィルターを使えば絞れますし。というかそこまでLTAに詳しくフィルターも書けて考えられるなら、権限取得してご自身の能力を活かしていただきたいです。--青子守歌（会話/履歴） 2020年7月26日 (日) 03:21 (UTC)

Aras ni kansha対策

不作成

目的	Arashi ni kansha、Ars ni kansha、Aras ni kanshaシリーズ対策
理由	WP:VIP#Arashi ni kanshaをご覧頂ければわかります様に、4月30日より非常に多く発生しブロックされております。これらを監視・対処するのは非常に負担が大きいので、編集フィルターで対処したいと思います。
発動条件	目的欄の文字列を含む利用者が、編集あるいはアカウント作成したとき
対処操作	不許可

個人用試験フィルター「編集フィルター#145」にて個人試験中です。 現在の検出状況は「編集フィルター記録」をご覧下さい。 基本的にはブロックしたいと思いますが、不適切と思われる方が多ければ不許可にします。ブロックの場合、種別とか期間は指定出来るのでしょうか？ 個人試験中ではありますが、アカウント作成の検出が上手くいきません。詳しい方、ご教授願います。アカウント作成が検出できれば、アカウント作成時の発動としたいと思います。 仮試験ということで検出する利用者名（文字列）は現在アクティブな「Aras ni kansha」だけにしています。

発動条件のコード

/* 編集 */
action==="edit"
/* アカウント作成 */
| action==="createaccount"
| action==="autocreateaccount"

/* ユーザー名がAras ni kanshaシリーズ */
& ( contains_any(user_name, "Aras ni kansha") |
    contains_any(accountname, "Aras ni kansha") )

--えのきだたもつ（会話） 2020年6月17日 (水) 16:05 (UTC)

コメント 編集フィルターによるブロック操作は標準だと実行できない設定となっているため、現時点で対処操作にブロックを付与することができません（どこかで提案して合意を得られればシステム管理者に申請して有効化できると思います）。また、この手の荒らしは利用者名を不許可にしてもパターンを変えてアカウントを乱造してくるのではないでしょうか。利用者名＋投稿内容で判定して止めていったほうがもう少し効果を発揮できるのではないかと思います。--Marine-Blue^{talk✿contribs❀mail} 2020年6月17日 (水) 16:23 (UTC)

コメント これは単にmeta:Title blacklistで済む話ではないですか？（編集フィルターをいじるならWikipedia:編集フィルターのガイドラインぐらいは読んで理解しておいてほしいです）--青子守歌（会話/履歴） 2020年6月17日 (水) 17:12 (UTC)

• コメント User_nameじゃなくてaccountnameだと思うんですが・・・--Q8j（会話） 2020年6月17日 (水) 17:29 (UTC)

返信 (Marine-Blueさん宛) Wikipedia:編集フィルター#警告および通知の投稿ブロックの項目には「現在、この対処操作は日本語版ウィキペディアでは利用されていません」と書いてあったので、利用されていないだけで使えるものだと勘違いしていました。教えて頂き、ありがとうございます。

本荒らしに関しては、本家・模倣が入り混じってはいますが、どんなにブロックされても一貫して利用者名の接頭語を揃えて来ており、強いこだわりがありますので、不許可くらいでは乱造には移行しないでしょうし、移行するにしても違う接頭語に変更してくる可能性の方が高いと思われます。変更してきたら、その接頭語をフィルターに加えるだけで即応出来ますので、現在の検出状況を見る限りでは、高い効果は維持できると思われます。

返信 (青子守歌さん宛) ブラックリストも考えなかった訳ではなかったのですが、Marine-Blueさんも仰っている利用者名を変えてきた場合に、どんなに熟慮した正規表現だったとしても、再申請が必要になるだろうと思われます。そのたび申請する訳にもいかないでしょうし、申請から承認、反映までの時間を考えれば、編集フィルターを使用した方が、迅速に柔軟に対応出来るだろうと考えました。

返信 (Q8jさん宛) 確かに「操作の "createaccount" と "autocreateaccount" に関しては、作成されたアカウント名を調べるには accountname を使用します。」と思いっきり書いてありました。完全に見落としていました。ご指摘ありがとうございました。あと、「/* アカウント作成」とコメントが閉じていなかったので、例えaccountnameを使用していても、"createaccount" と "autocreateaccount"のactionが検出されていませんでした。合わせてコードを更新しておきました。過去の編集に対してテストした限りでは、本荒らしのアカウント作成も検出出来る事を確認出来ました。

以上、まとめて返信させて頂きました。--えのきだたもつ（会話） 2020年6月17日 (水) 19:48 (UTC)

コメントやコード修正により、冒頭の表を修正しました。--えのきだたもつ（会話） 2020年6月17日 (水) 19:58 (UTC)

• ちょっと考えてみました。
  • アカウント作成を禁止するのであれば編集を禁止する必要はないのではないでしょうか？
  • もともと単純に機械のフィルターで完全に防ぐのは無理なので、その前提で被害を軽減する方向で考えてみるのはどうでしょうか。
    • （１）action=='edit' & contains_any(user_groups,'autoconfirmed') & page_namespace=3 & page_title!=User_nameで1時間以内に7回以上で発動
    • （２）action=='edit' & user_age<1800 & page_namespace=3 & page_title!=User_name（アカウント作成後30分以内の利用者による他者会話ページへの編集禁止）
    • （３）シンプルに当該嵐がよく使うワードをadded_lineで弾く

とか。--Q8j（会話） 2020年6月18日 (木) 03:53 (UTC)

•  追記 2は巻き添えが出る恐れがありますね。３は少し文言を変えるだけですり抜けられるので僕としては1が一番無難かなって感じです。２は一昨日の深夜？くらい管理者がいるときならuser_ageを180（=3分）とかにすれば巻き添えを回避しつつ管理者がアカウント名に気付いてブロックするまでの時間を稼げるかもしれません。--Q8j（会話） 2020年6月18日 (木) 07:15 (UTC)

• コメント Q8jさん、色々考えて頂いて、ありがとうございます。何かこう色々と考えられたのを見てると楽しくなっちゃって本来の目的を忘れちゃいそうです。すみません、不謹慎で。
• さて、順々にお答えしていこうと思いますが、「アカウント作成を禁止するのであれば編集を禁止する必要はないのではないでしょうか？」→はい、その通りでございます。冒頭に書いた通り、アカウント作成が検出できれば、アカウント作成時の発動としたいと思っております。ご教授のお陰で検出できる様になりましたので、編集を禁止する必要はないと思います。個人試験でアカウント作成と編集が検出できる事を確かめたかったので、両方入っているコードとなっていますが、本番ではアカウント作成禁止のみで行こうと思います。
• 被害軽減方向で色々考えて頂いた事ですが、まずは本荒らしがブロックされずに完全に仕事を終えて去って行ったパターンが最近では「特別:投稿記録/Aras ni kansha 14」（事後で私がブロック）にございますので、ご覧下さい。これを見るとアカウント作成(22:31)直後から荒らし投稿を開始し、わずか15分後(22:46)に全部で27回の荒らし投稿を終えて去っています。およそ1分に2回のペースです。多少差異はありますが、途中ブロックの如何に関わらず、だいたいこんなパターンです。そうすると、Q8jさん案(1)で行くならば、時間を縮めるか回数を増やした方が良い様な気もします。ただ、アカウント作成禁止で行こうと思っていますので、ストック案とさせて下さい。折角色々と考えて頂いたのに、すみません。
• 現状、管理者の方々の対応は、早いときはアカウント作成直後にブロックして頂いている（私もアカウント作成直後にブロックしに行ってますが既にブロックされています）くらい監視を強化して頂いていると思います。ただ、それほどの監視をするのは、相当の労力の負担になってると思いますので、やはり編集フィルターでアカウント作成禁止が出来ればと思います。Marine-Blueさんご指摘の通り、利用者名パターンを変えて来る可能性は多いにありますが、変えても同一シリーズで揃えて来る可能性が高いと思いますので、そこは私が編集フィルターの登録文字列の更新で対応したいと思います。そのくらいなら、それ程負担になりませんので。如何でしょうか？--えのきだたもつ（会話） 2020年6月18日 (木) 18:33 (UTC)
  • 返信 まあ明らかに巻き添えはなさそうですし、そう仰るなら・・・。賛成します。破られたらフィルター変更、というので行けるならそれに越したことはないですし。--Q8j（会話） 2020年6月19日 (金) 09:45 (UTC)

• コメント Aras ni kanshaの荒らしに関してはアカウント作成を防止したいのならあまり意味はないと思います。そもそもJAWPローカルでアカウント作成を防ぐことはできません。meta:Title blacklist案件です。--Infinite0694（会話） 2020年6月19日 (金) 17:15 (UTC)

返信 (Infinite0694さん宛) 幾つか質問させて下さい。

• 「あまり意味はない」のは、どうしてでしょうか？
• 「アカウント作成を防ぐことはできません。」とは、編集フィルターでは技術的にアカウント作成を不許可に出来ないという事でしょうか？それとも、技術的には出来るが、やってはいけない、あるいは、しない方が良いという事でしょうか？

的外れな質問をしているかもしれませんが、お答え頂ければ幸いです。--えのきだたもつ（会話） 2020年6月20日 (土) 13:32 (UTC)

• コメント まず、前提として日本語版の編集フィルターではアカウントの作成を防ぐことは技術的に無理です。アカウントを作成すると、ローカルと、同時にメタとログインウィキに作成されることが原因だからです。もしやるのなら、正規表現を使ってmeta:Title blacklistで対応するのが良いかと思います。--Infinite0694（会話） 2020年6月21日 (日) 14:16 (UTC)

• コメント そうでしたか。出来ないと知らなかったとは言え、延々と発言して来てしまい、お恥ずかしい限りです。meta:Title blacklistで対応する場合は、こちらで追加をお願いする事になるのでしょうか？その場合、当然英語でのやり取りになると思うのですが、お恥ずかしい話ですが、英語が不得手なので、どなたかに代理申請して頂く事は可能でしょうか？正規表現パターンについては考えてマッチングチェック済みではあるのですが、ここで公表してしまうと荒らしに悟られる恐れがあると思うのですが、どこでチェックや検討をすればよろしいでしょうか？質問ばかりで申し訳ありませんが、お答え頂ければ幸いです。--えのきだたもつ（会話） 2020年6月21日 (日) 17:31 (UTC)

• @えのきだたもつ: ここはブラックリストの使い方や申請方法を聞くところはここではないので、別の適切な場所でお願いします。Wikipedia:利用案内か、非公開にしたいならsysop MLという手もあるかと思います。--青子守歌（会話/履歴） 2020年7月26日 (日) 03:30 (UTC)

議論が長期停滞していることに加え、そもそもjawikiでは不適切（作成困難）なフィルターということで一旦、却下扱いにしておきます。適切な条件を加えて編集を防ぐためのフィルターを作る場合は別途提案してください。--青子守歌（会話/履歴） 2020年7月26日 (日) 03:30 (UTC)

基本多言語面外の文字を含むページ名

提案中

目的	ページ名にUnicodeの基本多言語面(BMP)にない文字を含む場合は常に他のページへのリダイレクトとし、ページ内で追跡用テンプレートを使用するよう利用者に強制する
理由	Wikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けてでの事前提案によるものです。フィルターの作成を提案したのは私ですが、以下の発動条件はネイさんの2020年5月9日 (土) 05:19 (UTC)の発言から引用しています。追跡用テンプレートというのはTemplate:Title with non-BMPを指しています。
発動条件	「ページ編集（作成を含む）の場合」かつ「ページ名にBMP範囲外の文字を含む場合」かつ（「リダイレクトでない場合」または「リダイレクトであり、追跡用テンプレートがない場合」または「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」）
対処操作	警告・不許可

-- 本日晴天（会話） 2020年5月29日 (金) 11:23 (UTC)

• コメント 発動条件のうち、「ページ名にBMP範囲外の文字を含む場合」と「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」のところは正規表現を使わないと実現不可能と思われます。個人的には「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」については作品名や組織名などでわずかながらリダイレクトとしての需要があるのではないかと考えており、この部分の判定が特に複雑かつ高コストとであるから、条件から外した方がいいのではないかという気がします。あと利用者名前空間および利用者‐会話名前空間のページと、リダイレクトページの冒頭に即時削除タグを貼るといった編集については発動から除外する必要がありそうです。--本日晴天（会話） 2020年5月29日 (金) 11:23 (UTC)
• コメント 特別:不正利用フィルター/14やUnicodeのEmojiの一覧を参考にして発動条件のコードを作ってみたので、以下に提示します。長いので折りたたんでいます。間違いがあったらご指摘ください。--本日晴天（会話） 2020年6月7日 (日) 08:49 (UTC) コードを1か所修正。--本日晴天（会話） 2020年6月8日 (月) 11:24 (UTC)

発動条件のコード

/* 編集操作 */
( action === "edit" )

/* 利用者名前空間でも利用者‐会話名前空間でもない */
& ( ( page_namespace !== 2 ) & ( page_namespace !== 3 ) )

/* ページ名に基本多言語面にない文字を含む */
& ( page_title rlike "[\u10000-\u10ffff]" )

/* ページの冒頭に即時削除タグがない */
& !( rmwhitespace( lcase( new_wikitext ) ) rlike "^{{(template:)?(sd2?|即時削除2?(/[]+)?|delete)(}}|\|)" )

& (
	/* リダイレクトでない */
	( isRedirect := ( rmwhitespace( lcase( new_wikitext ) ) rlike "^\#(redirect|転送|リダイレクト):?\[\[.+?\]\]" );
	!isRedirect )
	
	/* リダイレクトであるが追跡用テンプレートがない */
	| (
		( isRedirect )
		& !( rmwhitespace( lcase( new_wikitext ) ) rlike "{{(template:)?title_?with_?non-bmp}}" )
		)
	
	/* リダイレクトで、ページ名が2文字以上、かつemoji入り */
	| (
		( isRedirect )
		& ( length(page_title) >= 2 )
		& ( page_title rlike "[\u1f004" +
		"\u1f0cf" +
		"\u1f170" +
		"\u1f171" +
		"\u1f17e" +
		"\u1f17f" +
		"\u1f18e" +
		"\u1f191-\u1f19a" +
		"\u1f1e6-\u1f1ff" +
		"\u1f201" +
		"\u1f202" +
		"\u1f21a" +
		"\u1f22f" +
		"\u1f232-\u1f23a" +
		"\u1f250" +
		"\u1f251" +
		"\u1f300-\u1f321" +
		"\u1f324-\u1f393" +
		"\u1f396" +
		"\u1f397" +
		"\u1f399-\u1f39b" +
		"\u1f39e-\u1f3f0" +
		"\u1f3f3-\u1f3f5" +
		"\u1f3f7-\u1f4fd" +
		"\u1f4ff-\u1f53d" +
		"\u1f549-\u1f54e" +
		"\u1f550-\u1f567" +
		"\u1f56f" +
		"\u1f570" +
		"\u1f573-\u1f57a" +
		"\u1f587" +
		"\u1f58a-\u1f58d" +
		"\u1f590" +
		"\u1f595" +
		"\u1f596" +
		"\u1f5a4" +
		"\u1f5a5" +
		"\u1f5a8" +
		"\u1f5b1" +
		"\u1f5b2" +
		"\u1f5bc" +
		"\u1f5c2-\u1f5c4" +
		"\u1f5d1-\u1f5d3" +
		"\u1f5dc-\u1f5de" +
		"\u1f5e1" +
		"\u1f5e3" +
		"\u1f5e8" +
		"\u1f5ef" +
		"\u1f5f3" +
		"\u1f5fa-\u1f64f" +
		"\u1f680-\u1f6c5" +
		"\u1f6cb-\u1f6d2" +
		"\u1f6d5" +
		"\u1f6e0-\u1f6e5" +
		"\u1f6e9" +
		"\u1f6eb" +
		"\u1f6ec" +
		"\u1f6f0" +
		"\u1f6f3-\u1f6fa" +
		"\u1f7e0-\u1f7eb" +
		"\u1f90d-\u1f91e" +
		"\u1f920-\u1f927" +
		"\u1f930" +
		"\u1f933-\u1f93a" +
		"\u1f93c-\u1f945" +
		"\u1f947-\u1f94b" +
		"\u1f950-\u1f971" +
		"\u1f973-\u1f976" +
		"\u1f97a-\u1f9a2" +
		"\u1f9a5-\u1f9aa" +
		"\u1f9c0" +
		"\u1f9ae-\u1f9ca" +
		"\u1f9cd-\u1f9fe" +
		"\u1fa70-\u1fa73" +
		"\u1fa78-\u1fa7a" +
		"\u1fa80-\u1fa82" +
		"\u1fa90-\u1fa95]" )
		)
	)

別案1

上で示した発動条件は複雑なので、別の案として「ページの編集操作である（作成を含む）」かつ「利用者名前空間でも利用者‐会話名前空間でもない」かつ「ページ名にBMP範囲外の文字を含む」かつ「{{Title with non-BMP}}を使用していない」という発動条件を提案します。要はページ名にBMP範囲外の文字を含む場合に追跡用テンプレートの使用のみを強制するということです。コードは以下のようになり、当初の案と比べてかなり簡単になります。

/* 編集操作 */
( action === "edit" )

/* 利用者名前空間でも利用者‐会話名前空間でもない */
& ( ( page_namespace !== 2 ) & ( page_namespace !== 3 ) )

/* ページ名に基本多言語面にない文字を含む */
& ( page_title rlike "[\u10000-\u10ffff]" )

/* 追跡用テンプレートがない */
& ( rmwhitespace( lcase( new_wikitext ) ) rlike "{{(template:)?title_?with_?non-bmp}}" )

この案ですとリダイレクトでない状態で作成したり、リダイレクトを解除するような編集は許可するということになります。そのような編集を行うと{{Title with non-BMP}}が（Category:Unicode基本多言語面外の文字を含むリダイレクトではなく）Category:Unicode基本多言語面外の文字を含むページ名を付与する仕組みになっているため、ウォッチリストを活用すれば追跡は容易です。--本日晴天（会話） 2020年6月7日 (日) 08:49 (UTC) 下線部を追記。--本日晴天（会話） 2020年6月7日 (日) 09:14 (UTC) コードを1か所修正。--本日晴天（会話） 2020年6月8日 (月) 11:24 (UTC)

移動荒らし防止フィルター

LTA:SZMYがおとなしくなったと思ったら次はLTA:3SBか、まったく・・・

下記２つ提案します。

提案中

目的	省略（下記記載）
理由	省略（下記記載）
発動条件	投稿回数100回未満の利用者が、1時間以内に5回以上ページ移動を行った時（20200806修正）
コード	action == 'move' & user_editcount < 100　（と60分以内に5回以上）
対処操作	不許可

提案中

目的	省略（下記記載）
理由	省略（下記記載）
発動条件	投稿回数100回未満の利用者が、 リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時 ページ作成から5分以内のページを移動しようとした時
コード	user_editcount < 100 & ( ( action=='edit' & page_age < 600 & contains_any ( old_wikitext , '#転送') ) | action == 'move' moved_from_age < 300 )
対処操作	不許可

この２つで移動荒らしを対処可能にすることを目的とします。

１つ目のフィルターにより、1時間以内に行える移動荒らしは3回が限度となり、差し戻しもしやすくなります。２つ目のフィルターは,#移動荒らし対策同様、リダイレクトページをいじられることで差し戻しが一般利用者にできなくなることを防ぐことを目的としています。

いずれも編集回数100回以上の利用者は対象外としています。これは複数のソックパペットが同時に移動荒らしを行った場合、アカウントの数が荒らし＞差し戻し者であった場合、差し戻しをこのフィルターが邪魔することになりかねないとの判断です（50回とするのも考えたんですが、極稀に「荒らしてるうちに編集回数が50回を超える」荒らしがいるので）

２つ目のフィルターについて、TmvYosizuyaさんより巻き添えの可能性のご指摘がありましたが、10分以内、とある通り10分待てば編集できるのであまり問題にはならないと思います。もともとリダイレクトページなんてそうそう編集されるものじゃないので。--Q8j（会話） 2020年5月28日 (木) 16:58 (UTC)事実誤認を修正。大変失礼しました。--Q8j（会話） 2020年5月28日 (木) 18:05 (UTC)

賛成 普通の利用者なら10分ぐらい待てますが、荒らしであれば早急に荒らさないとブロックされるので、そういった意味で有用な編集フィルターであると思います。1つ目の編集フィルターで、投稿回数100回未満の利用者が行った移動にタグ付けをするとかそういうのがあってもいいと思いますが、まあそれについてはどちらでもいいと思いますし、初心者の方が「なんだこれ？？」となるかもしれないのでタグ付けはなくてもあってもどちらでもいいです。--Tmv（会話|投稿記録） 2020年6月19日 (金) 00:46 (UTC)

• コメント 「もし、提案後1週間が経過し、2人以上の賛成（提案者の提案者票を含めても良い）があり、かつ反対する人がいない場合は、合意がなされたとみなされます。」の要件を満たし、本件フィルターは合意がなされています。本日、LTA:203と思われる移動荒らしが２体出現したこともあり、可能ならフィルター作成をおねがいしたいです。--Q8j（会話） 2020年7月18日 (土) 10:18 (UTC)typo--Q8j（会話） 2020年7月18日 (土) 10:19 (UTC)取り消し。一旦--Q8j（会話） 2020年8月6日 (木) 12:36 (UTC)

---

• コメント コードを書いてみて気付いたんですが、何個か訂正しました。
  • 一つ目。1個目のフィルターの発動条件回数を変更しました。5回以上で発動としています。理由として、多分、ですが「ノートページも移動」にチェックした場合、移動が2回カウントされてしまうと思います。そうなると1時間以内の移動を3回まで、としてしまうとノートも同時移動とすると事実上1回までしか移動できなくなってしまいます。なので２倍にしたいところですが、逆に6回まで許可、とすると荒らしがノートを移動しなかった場合や、ノートが存在しないページへの移動荒らしだった場合6回まで移動荒らしができてしまう。これはさすがにあまりよろしく無いだろう、と思い、それの中間という感じで4回まで許可（5回目以降は不許可）としました。つまりノートも同時移動した場合であっても2回までは移動可能です（編集回数を満たす人は当然影響されません）。
  • 2つ目。2個目のフィルター、つまりリダイレクトを編集されて一般利用者に差し戻しができなくなる事態を防止するフィルターですが、「移動する時のウィキテキスト」が取得できなさそうです（てっきりできると思ってたんですが）。ので、苦肉の策ですが「作成後5分以内は（リダイレクトかそうでないかにかかわらず）移動できない」としました（user_editcount＝編集回数は使えるので100回以上の利用者は移動は可能です）。新規利用者が作ったばかりのページを移動したくなった場合（WP:NC違反に気づいた時など）は案内文を表示して5分待ってから移動してください、というようにしたいと思います。なお、編集の際はold_wikitextが使えますので、編集の際は当初提案通り「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」となります。

以上です。賛成票を投じていただいたTmvさん、この変更後でも賛成していただけますか。他の皆さんはいかがでしょう。大幅に条件を変えたので、意見募集期間を振り出しに戻し、追加1週間（最低）とします。また、old_wikitextなど負荷が高いものを使っていますので、負荷軽減のためにいい案がある方は教えていただけると助かります。--Q8j（会話） 2020年8月6日 (木) 12:36 (UTC)

意図の分からない重大編集の抑制

提案中

目的	意図の分からない重大編集の抑制
理由	「記事への重大（大胆）な編集」について、要約欄の記入を必須とすることで、意図を明確にさせるため
発動条件	「記事への重大（大胆）な編集」（詳細は下を参照）が行われようとしていて、かつ要約欄が空 (summary == "") である時
対処操作	警告・不許可

「記事への重大（大胆）な編集」として次を想定しています。

1. 記事の分量を一定程度（詳細については議論しましょう）減少させる編集

   Wikipedia:ウィキペディアについてでは、「ウィキペディアは、信頼されるフリーなオンライン百科事典、それも質・量ともに史上最大の百科事典を、共同作業で創り上げることを目的とするプロジェクト」とかかれており、記事の分量を減少させる編集については、「質・量ともに史上最大の百科事典を、共同作業で創り上げる」という観点からは逆行するように思えるため。もちろん、冗長な箇所を削除したり、Wikipedia:ウィキペディアは何ではないか#ウィキペディアは情報を無差別に収集する場ではありませんに抵触する部分を削除したり、法的な問題が惹起される編集を指し戻す場合もありますが、このような場合は要約が提供されてしかるべきです。

2. Category:存命人物にカテゴライズされている記事に対して、「逮捕」「麻薬」「覚せい/（醒）剤」「MDMA」「不倫」などのネガティブワードを追加する編集

   Wikipedia:存命人物の伝記・Wikipedia:削除の方針#ケース B-2:プライバシー問題に関してに提唱する可能性のある編集であるため。

3. Infobox系テンプレートの「名前」「name」「愛称」「nickname」「正式名称」「official name」系パタメーターの引数を変更する編集

   人物・企業の名称は頻繁に変わるものではないことと、この種の編集はしばしば記事の対象が炎上等していて、ウィキペディアにも悪戯が出没しているケースが多いように思われるため。例として、茅原実里・富山県警察・高輪ゲートウェイ駅を挙げておきます。

これも「記事への重大（大胆）な編集」にあたるのではないか、あるいは上の編集の内これは「記事への重大（大胆）な編集」ではないという意見も含めて、意見を賜りたいです。 片割れ靴下（会話） 2020年5月20日 (水) 17:57 (UTC)

3番目を追加しました。 片割れ靴下（会話） 2020年5月20日 (水) 18:05 (UTC)

• 質問 このフィルターの目的は、「荒らしをこれによって防ぐ」ことでしょうか？それとも要約欄に書かない初心者や書き忘れた人に案内することでしょうか？--Q8j（会話） 2020年6月1日 (月) 12:28 (UTC)
  • 色々です。例えば金田一少年の事件簿 (アニメ)でのある編集は、編集者がなぜこうした「おまじない」が存在するのか理解しないで削っているのか、この「おまじない」が折りたたみや2列での表示のためだとわかっていて、削ろうとしているのかという説明が提供されれば、差し戻すべきか差し戻さないべきかという判断を下しやすくなります。プライメイトシティでのある編集は、ビジュアルエディターを使わずに大規模な票を編集してしまったために、レイアウトが大きく崩れてしまっています。通常、こうした編集への対応は差し戻しが主流ですが、この人がこの編集でしたかったことを要約欄で教えてくれれば、単なる差し戻しではなく、この人の意向をくんだ表組みの修正という選択肢も出てきます。また、要約欄を書かないと荒らせないようにすることで荒らしの速度を少しでも低下させたり、手間を掛けさせることができると思います。 片割れ靴下（会話） 2020年6月1日 (月) 13:12 (UTC)

半保護突破のための編集数稼ぎ防止

提案中

目的	半保護突破のための編集数稼ぎ防止
理由	同上
発動条件	編集回数500回を満たさないユーザーが ・自らの利用者ページ、利用者ノート、利用者サンドボックスを少ないバイト増減（100バイト未満、随時見直し）で、複数回編集を繰り返す ・ある特定ページを複数回、少ないバイト増減（100バイト未満、随時見直し）で、複数回編集を繰り返す
対処操作	不許可

LTA:ASPEやLTA:203、LTA:Iccicなどで、半保護突破を目的とした編集数稼ぎが多く発生しています。実現可能なものから早期に実装し、必要に応じて随時拡張をお願いしたいと思います。--Taisyo（会話） 2020年2月2日 (日) 03:46 (UTC)

• 賛成 --Q8j（会話） 2020年3月6日 (金) 11:48 (UTC)--Q8j（会話） 2020年4月29日 (水) 08:38 (UTC)
• コメント Wikipedia:井戸端/subj/Wikipedia:サンドボックスの長期間半保護についてを見てやってきました。基本的には同意ですが、「複数回編集」の定義を明瞭にしていただきたいです。少なくとも、1.どれ位の時間間隔で、2.何回編集した場合に、「複数回編集」と見なされるのか、という条件ははっきりさせておいて欲しいです。もちろんバイト数の条件と同様に随時見直しはされるべきです。--Loasa（会話） 2020年4月1日 (水) 02:58 (UTC)

• 明言したくない理由をお話ししたいと思います。編集フィルターは荒らしへの抑止力と誤爆が少ないを両立させないといけません。間隔や回数ですが、技術的に出来るかどうかの確認の要素がありまして、実際に出来ること出来ないこと。また、出来たとして、どのようなことが出来るのか確認したい部分があります。出来る事の仕様書を頂いた上で、細かい仕様を出すことになると思います。その中で、非公開事項も出てくると思いますし、随時変更もあるとしています。--Taisyo（会話） 2020年4月1日 (水) 10:20 (UTC)

• 仕様について。仕様書がわかりにくいので、ほかの方の再確認があれば心強いです。
  • 発動条件で使用できる情報（仕様書）：特定の編集に対し、「編集したページ名と名前空間」「バイト数の増減」を検出できます。「当該ページに投稿した、直前の10人」「ページ作成者」も検出できますが、パフォーマンスが悪いのであまり推奨できません。利用者の情報は「アカウント作成日時から経過した秒数」「編集回数」を取得できますが、「これまで特定ページを編集した回数」は取得できません。
  • 対処操作（仕様書、ただし一部英語のまま）：「X秒内にY回以上フィルターにひっかかる操作（編集）を行った場合のみ」「自動承認ステータスを取り消す」「操作を不許可」とすることができます。また、この「X秒内にY回」についてですが、「同じIPアドレス」「同じIPレンジ（/16レンジ）」「同じ利用者名」「アカウント作成日が同じ利用者」「対象ページが同じ」といったグループごとに限定できます。editcountグループ＝「編集回数が同じ利用者」も指定できますが、正直使い道がわかりません。また、登録利用者の場合、IP利用者と「同じIPアドレス」のグループにもカウントされるかについてはわかりませんでした。
    • わかりにくいと思いますので、例を挙げます。対処操作に「自動承認ステータスを取り消す」「不許可」を、頻度制限を「60秒内に3回」「アカウント作成日が同じ利用者」「対象ページが同じ」とします。その場合、2020年3月1日にアカウントを作成した全ての利用者（以下グループZとします）は60秒間に合計3回、ページAを編集することができます。その60秒間にグループZの利用者がさらにページAへの編集を保存しようとした場合、保存できない上に自動承認ステータスが取り消されます。一方、2020年3月2日にアカウントを作成した全ての利用者はグループZとは別にページAを60秒間に合計3回編集できます。
• すなわち、私の理解が正しければ、Taisyoさんが作成しようとしている編集フィルターは技術上可能であると思います。--ネイ（会話） 2020年4月1日 (水) 13:01 (UTC)

忙しくなったのと、仕様理解に苦労していたので返事が遅れました。とは言いつつも理解し切れていません。処理負荷を考慮しなければ、かなり細かく見ることが出来るみたいですが、負荷の大きい仕様は良くないと思います。仕様を端折るなどして、比較的低負荷なフィルターの構築をお願いしたいと思います。--Taisyo（会話） 2020年4月12日 (日) 13:19 (UTC)

• これ以上編集できなくなるという回数が3回目以降の連続編集のたびに表示され、善意によるプレビュー不使用編集に対応することを条件に賛成します。わかりやすく言えば、「同一利用者が、1時間以内に5回同一ページを編集した時、6回目の同一ページ編集を不許可とする」という編集フィルターを作る場合、3回目の編集の時は、「ウィキペディアへの過剰負荷防止と荒らし防止の観点から、可能な限りプレビュー機能を利用するようにしてください。◯◯分以内にあと2回このページを編集すると、このページへの編集ができなくなります。」と表示され、4回目の編集の時は前掲メッセージにおいて「あと2回」を「あと1回」に置き換えたものが表示され、というように悪意でない編集に対してプレビュー機能の利用を促すことで、善意の利用者に対する啓発や対策をすることが必要だと思います。 片割れ靴下（会話） 2020年4月27日 (月) 02:04 (UTC)
• フィルターの目的の性質上、非公開とせざるを得ない仕様が多いことは理解しています。それでも極力仕様のオープン化および詳細化を求める理由は、このフィルターは副作用の害がかなり大きいと考えられるためです。一番ありえる問題は、本来阻止したい「半保護突破のための編集数稼ぎ」をするLTAなどでない、単なる「不慣れで少しずつ編集をしている初心者」や「利用者ページ（もしくはサンドボックス）で練習をしている初心者」などが引っ掛ってしまうことです。

そのような場合に、被害の程度がどれくらいのものになるのか、はフィルターの仕様（特に対処部分）に依りますが、たとえば、一度フィルタが発動したら二度とそのページに投稿できない、とか、「自動承認された利用者ステータス」がリセットされて二度と「自動承認された利用者」になれない、といった仕様だと、善意の初心者にとって非常に大きな（場合によっては致命的な）被害になります。

これはほんの一例です。こういったことをいろいろと想定して考えれば考えるほど、少くとも「発動条件」「対処」「一回対処した後の利用者に対する制約」などの仕様をかっちり詰めていただかないと、悪意のない初心者が巻き込まれる（しかも本人には対処できない状態になる）可能性が高い、このようなフィルターはとうてい安心して承認できません。また、悪意のない初心者がフィルターに引っ掛ってしまい、編集ブロックとかステータスのリセットなどの被害に巻き込まれた場合のフォロー手段と手順についてもきちんと決めておく必要があります。

以上のような理由から、対処としては単に「フィルターが発動した段階でその投稿を不許可にする」だけなのか、その段階で「自動承認ステータスを取り消す」のか。その場合再び編集履歴を積み重ねても自動承認ステータスはえられないのか、さらに、一度フィルターの発動条件に引っ掛って編集不許可となったら、そのユーザーは二度とそのページに投稿できないのか、等々、いろいろな発動条件と対処を前もってきちんと議論し、仕様化してから実装していただきたいと思います。仕様を端折るなんてとんでもないことです。

少くとも、そういった議論がなされ仕様がしっかりと整られない限り、このフィルターの作製と使用には反対と言わざるを得ません。とりあえず作って運用してみて何か問題があったらその都度修正していけばいいじゃん、というやり方は、害が少ないフィルターならそれでも良いのですが、このような副作用の害が大きいフィルターについては取るべきではありません。--Loasa（会話） 2020年4月29日 (水) 02:29 (UTC)

• （追記）上の片割れ靴下さんのご提案は、私にはまったく思い付きませんでしたが、非常によい方法だと思います。これは安全装置の一つとして、ぜひ仕様に取り入れていただきたいですね。その他にもこの種のフィルターでは、安全装置に相当する仕様を過剰なくらいに取り入れて設計していだきたいと思います。--Loasa（会話） 2020年4月29日 (水) 02:32 (UTC)

別に過剰な安全装置の否定をしているわけではないです。もし、片割れ靴下さんのご提案で実際にフィルターが作れるのか。また、そうしたときに過剰な負荷が掛からないか、私も確認したいと思います。確かに、注文を全部取り入れられて、負荷が大した事なければ、理想に思います。--Taisyo（会話） 2020年4月29日 (水) 03:01 (UTC)

• 仕様についてお答えいたします。こちらもほかの方の再確認があれば心強いです。
  • 「自動承認ステータスを取り消す」の対処操作：これは取り消しから5日間自動承認されない仕様となっており、以降は再び自動承認ステータスが与えられます。
  • 一度引っかかったら二度とそのページ投稿できないのか：「X秒内にY回以上」なので、一度引っかかったら「X秒内にY回以上」を満たさなくなるまで投稿できません。プレビューはできます。
  • これ以上編集できなくなる前に警告する操作：警告に使用するシステムメッセージは1フィルターにつき1つしか設定できず、メッセージ側で編集回数は取得できません。また、「X秒内に3回」「X秒内に4回以上」という場合分けもできません（「X回以上」しか設定できません）。したがって、片割れ靴下さんのご提案は技術上実装できないと思います。
• 私見ですが、無関係な被害とLTA対策の均衡は「X秒内にY回以上」の「X秒」の設定によると思います。これを短くすればするほど、無関係な被害が減るものの、LTA対策としての効果も低下します。--ネイ（会話） 2020年4月29日 (水) 04:12 (UTC)

• 返信 (ネイさん宛) ネイさんありがとうございます。詳細についてまだいろいろと不明な点があるので確認および質問をしたいと思います

A「自動承認ステータスを取り消す」：

A-1. これは、すでに自動承認されていても取り消されて新規利用者とされる、ということですね。「取り消しから5日間承認されない仕様」ということは、その５日間はどんなに多くの編集をしても「自動承認された利用者」にならない、ということでしょうか。

返信 その認識で合っています。

A-2. また、5日間経過したら即座に「自動承認された利用者」に戻れるのでしょうか。それとも取消しの瞬間にリセットされ、5日間経過した後さらにまた４日経過し１０回以上の編集がないと「自動承認された利用者」に戻れないのでしょうか。

返信 試していないので、確かな答えは現時点では提供できませんが、おそらく「5日後に即座に自動承認される」と思います。（1回編集する必要のある拡張承認とは仕様が違います）

A-3. また、「5日間」という期間は仕様上固定されたものでしょうか。設定でこの期間を変更することはできないのでしょうか。

返信 現時点では正確には「432,000秒」（＝120時間＝5日）に固定されており、変更はできません。

A-4. また、「自動承認された利用者」になる以前の段階で取消しになった場合はどうなるのでしょうか。やはり５日間は何をしても「自動承認された利用者」にならないのでしょうか。

返信 その認識で合っています。

B.「X秒内にY回以上フィルターにひっかかる操作を行った場合のみ発動」：

B-1. これは同じページの編集に対してのみ発動するのですね。同一の利用者が投稿先を次々と変えて編集した場合は、「X秒内にY回以上」の編集をしても発動しないのですね。（というよりそういう条件は検出はできないかもしませんが）

返信 「X秒内にY回以上」は正確には「フィルターの発動条件にひっかかる編集をX秒内にY回以上」なので、フィルターの発動条件によります。たとえば、Wikipedia:サンドボックスでの編集のみ検出するという条件の場合、投稿先を変えることでフィルターにひっかからなくなり、回避できます。条件のほうで調整することになります。

B-2. 必然的に、あるページの編集に対してフィルターが発動してしばらく投稿できない状態になったとしても、別のページでは普通に投稿できるのですね。

返信 フィルターの発動条件にひっかからない編集であればできます。たとえば、バイト数変動が+100未満の場合のみ検出する場合、バイト数変動を+100以上にすることで投稿できるようになります。

C.フィルター発動後に投稿再開できる条件：「「X秒内にY回以上」を満たさなくなるまで投稿できません」どうもよくわからないし、これが肝心なところですので具体的な数値例で詳しく伺いたいと思います。仮に「60秒内に10回以上」の投稿で発動する設定とします。

C-1. この場合、フィルターが発動してから何秒経過したら次の投稿が出来るようになるのでしょうか。早ければ数秒以内、最長でも60秒経過すれば次の投稿ができるのでしょうか。

返信 最長でも60秒経過すればできます。

C-2. また、この条件にさらにバイト数の制約を入れ「60秒内に100バイト未満の編集を10回以上」とした場合はどうでしょうか。この場合は、フィルター発動直後でも100バイト以上であれば投稿できるのでしょうか。

返信 その認識で合っています。（B-1、B-2への回答も参照）半保護されたページの場合は自動承認が取り消されているため投稿できません。

いろいろと御手数おかけしますが、よろしくお願いします。--Loasa（会話） 2020年4月29日 (水) 07:02 (UTC)

• 追加質問です。

A-5. 取り消されてから５日の間に再びフィルターの発動条件に引っ掛った場合、自動承認されない期間はその分延長されるのでしょうか。たとえば、最初に取り消されてから４日目に再びフィルターに発動された場合、最初に取り消されてから9日後まで承認されないということでしょうか。

返信 対処操作が発動するごとに自動承認できるまでの期間が5日にリセットされるので、最後の発動から数えて5日間自動承認されないことになります。

--Loasa（会話） 2020年4月29日 (水) 07:20 (UTC)

インラインにて回答いたします。かなり複雑な仕様なので、繰り返しになりますがほかの方の再確認があれば心強いです。--ネイ（会話） 2020年4月29日 (水) 07:56 (UTC)

そうなるでしょうね。技術書を読み込んでいるわけではないので経験則で。基本的に一般利用者は、新登録者（半保護記事の編集が出来ない）→半保護記事が編集できる利用者（従来の一般利用者）→拡張半保護記事が編集できる利用者を基本的には一方通行で上ることになります。フィルター用件によっては、引っかかる限り新登録者に留め置くことは出来ますし、半保護記事が編集できる利用者を新登録者に格下げすることも出来そうです。ただ、その閾値は固定です。これが半保護や拡張半保護の仕組みですので。--Taisyo（会話） 2020年4月29日 (水) 08:15 (UTC)

• 返信 (ネイさん宛) 　ありがとうございます。まだよくわからない部分があるので、しつこいようですが再度質問させていただきます。

B.「フィルターの発動条件によります。」「条件のほうで調整することになります。」というのがよくわかりません。

B-3.結局のところ、「同一の（つまり同じ利用者名の）利用者が、投稿先に関係なく（次々と投稿先を変えたとしても）トータルでX秒内にY回以上の編集をした場合」に発動する、という設定も可能ということでしょうか。(とりあえずバイト数による制限はしない、という仮定でお願いします）

そこまで条件を緩めるのは無理でも、せめて対象の投稿先を単一ページではなく名前空間レベルまで拡張して指定することはできますか。たとえば標準名前空間を指定したとすれば、「標準名前空間であればどのページでも（途中で投稿先を変えても）X秒内にY回以上の編集をした場合に発動（この場合、発動前に投稿先をWikipedia名前空間に変えれば、その投稿はX秒内にY回以上の編集にカウントされない）」という設定はできるのでしょうか。

--Loasa（会話） 2020年4月29日 (水) 09:07 (UTC)

返信 発動条件では「投稿先に関係なく」でも、「特定の1ページまたは数ページ」「特定の1名前空間またはいくつかの名前空間」の組み合わせでも設定できます（正規表現も使用できます）。すなわち、LoasaさんがB-3で挙げた条件はいずれも可能です。--ネイ（会話） 2020年4月29日 (水) 09:14 (UTC)

• ありがとうございました。ネイさんのおかげで、いろいろと出来ること出来無いこと危険なことなどがわかってきて具体的なイメージが見えてきたので、具体的な仕様案を出してみます。ネイさんの解説に対する私の理解が間違っていなければ、以下のようなフィルターは実装可能のはずです。

F1.目的と理由については当初の提案通り

F2.対象となる利用者：

F2-1.編集回数500回を満たさないアカウントユーザー。

F2-2. ただし、編集回数500回を超えるアカウントユーザー、およびIPユーザーは対象外

F3. 対象となるページ：

すべてのページ

F4. 発動条件：

F4-1. 対象となる利用者が、対象となるページに対して、「投稿先に関係なくT秒間にBバイト未満の投稿をN回以上繰返した場合」に発動。（つまり、投稿先が変動しても頻度の条件を満せば発動）。T、B、N、の具体的な数値は、フィルターの性質上非公開にするのはやむをえないでしょう。

F4-2. ただし、TとBには上限値、およびNには下限値を定め、その上限値と下限値は公開し、調整はそれらの値の範囲内で行うものとする。

F5.発動時の対処：

F5-1.「T秒間にBバイト未満の投稿をN回以上」の条件を満たさなくなるまで、対象となるすべてのページに対する投稿を禁止する。（実質的には最大T秒間の投稿ブロックということになります）

F5-2.警告メッセージが表示される。メッセージの内容は、たとえば、「フィルターが発動したため、あなたはT秒間Wikipediaへの投稿ができません。ウィキペディアへの過剰負荷防止と荒らし防止の観点から、可能な限りプレビュー機能を利用するようにしてください。」このメッセージにおける「T秒間」には、実際の設定値にかかわらず、F4-2.で公開されている最大値を指定する。

F5-3.ただし、自動承認ステータスの取消しはしない

解説：

「自動承認ステータスの取消し」はたしかに編集回数稼ぎのLTAには非常に有効ですが、効き目の強い薬ほど副作用も大きいことと同様に、この機能もまた有害な副作用が大き過ぎます。ネイさんの御説明によりその危険性がよくわかりました。その有害な副作用に対する有効な安全対策が取れない以上（片割れ靴下さんのご提案は安全対策としてかなり有用な方法だと思いますが、実装できない以上どうしようもありません）、この対処は導入すべきではありません。また、対処が実質的に「T秒間の投稿ブロック」となる以上、どれくらい待てば良いのかわからないのは特に初心者にとって不安かつ迷惑であり、第三者が「ちょっと待っててね」とアドバイスしたくても具体的な解除時間がわからないとそれも言い難いので、上限値の設定と公開は必須としていただきたいと思います。

私は、当フィルターに関しては、極力、無関係な被害者が出ないように、また被害が最小限に留まるように、という観点を重視して考えています。もちろんそれは当フィルターの本来の目的ではないので、本末転倒と言われても仕方無い。しかし、何度も繰返し述べているように、このように副作用の害が大きいフィルターでは当初の目的に対する効果が多少落ちる結果になってでも副作用の害を予防することが最重視されるべきと考えるからです。

--Loasa（会話） 2020年4月29日 (水) 10:48 (UTC)

上限値及び下限値の公開について。気持ちはわかるのですが、それを狙ってLTAが編集稼ぎをするのではと思います。つまりは「理想を高く持ったために現実が低くなりかねない」状態に思います。そもそも、明言をしないまでも誤爆率を減らすことは当然のことです。大きく分けて、狙っている対象に確実にHITした（これが理想です）・本来は狙っていない対象にHITしたが実際のところは荒らし編集だった（たちまち問題はないが、誤爆原因の一因になる可能性があるのである程度は検討は必要）・完全な誤爆（これは要対応）とに分かれるように思います。極端に高い閾値にしたら誤爆率も高くなります。上限値公表はこのようなリスクを抱えています。先の話で、丸投げ話にしたのは、技術的にも十分理解していると判断しているので、仕様などの作成に対し、信用しても良いと思ったからです。とりあえずは、Loasaさんの仕様をベースにするにしても、上限値・下限値の公表は慎重にしたほうがいいかもしれません（CUの保持期間の非公表もそれが理由です）。--Taisyo（会話） 2020年5月1日 (金) 09:09 (UTC)

当然ですが、ある程度の取り漏らしも織り込み済みです。正常な編集も誤爆するリスクがあるからで、何割か減れば程度で最初から組んでいます。--Taisyo（会話） 2020年5月1日 (金) 09:11 (UTC)

視点を変えて、少しでも半保護突破用アカウントを作りづらくするための編集フィルタ―として考えるのはどうでしょうか？条件を厳しくする代わりに、頻繁に警告文を表示させて、半保護逃れ用編集の速度を遅らせるのです。これなら不許可という強硬な対処ではないので、回数や時間について公表する必要は薄くなると思います。ところで、半保護を突破しようという人たちは、自動承認された利用者がどうすれば手に入るのかを熟知して「犯行」に及んでいるものと思います。であるなら、回数・時間といった値を非公開にしても事前調査などの形で、値が検証され、露見してしまうかもしれません。つまるところ、非公開とする意味合いは大きくないのではないと思うのですが、その点はいかがでしょうか？ 片割れ靴下（会話） 2020年5月1日 (金) 12:33 (UTC)

元々、0にするべくフィルターを作っているわけではないです。幾らかの取り漏らしを前提には作っています。とはいえ、前段階の警告フィルターの件。2つフィルターを作れば理屈の上では成立します。同じ内容のフィルターで閾値と対応を分けて、仮に「10件の編集で警告を入れる」と「20件の編集で編集を認めない」の2つのフィルターを用意したら、実現できます。--Taisyo（会話） 2020年5月1日 (金) 13:01 (UTC)

不適切なリダイレクトの作成防止

提案中

目的	LTA:203などによる曖昧さ回避のついたリダイレクトの乱造対策
理由	曖昧さ回避括弧のついたリダイレクト自体必要性か低く、有用である場合が少ないため。
対処操作	警告、タグ付け

-- そらたこ（会話） 2019年11月21日 (木) 23:21 (UTC)

• コメント 「(曖昧さ回避)」のつかない形での曖昧さ回避ページが有る場合、「項目名 (曖昧さ回避)」というリダイレクトが作成される場合があり有用です。曖昧さ回避のカッコ内が「曖昧さ回避」である場合は回避したほうが良いかもしれません。不許可にしないのであればそこまで気にすることはないですが。--Yuukin0248[会話/投稿記録] 2019年11月22日 (金) 09:03 (UTC)
• コメント Wikipedia:記事名の付け方/ヨーロッパ貴族の記事名では「公爵侯爵伯爵について“爵”の有無は定めませんが、もう一方の記事名からリダイレクトを作成しておくことを推奨します」とあり、実例としてトマス・ペラム＝ホールズ (初代ニューカッスル公)とトマス・ペラム＝ホールズ (初代ニューカッスル公爵)がありますので、作成する場合はそれも回避する必要があると思料します。--ネイ（会話） 2019年11月22日 (金) 16:27 (UTC)
• コメント 「(曖昧さ回避)」以外での括弧付きリダイレクトの事実上の作成半保護という形だとどうなのでしょうか？つまり、IP利用者・新規利用者（自動承認されていない利用者）が「(曖昧さ回避)」以外での括弧付きリダイレクトを作成しようとした場合に不許可とする、ということです。LTA:203の荒らしの大半は半保護で抑え込めると思います。「(曖昧さ回避)」以外での括弧付きリダイレクトが有用な場合はそれほど多くはないように思います。もし必要ならノートなど適切なページで告知すれば誰かしらログインユーザーが対応できそうに思います（もしくは、大量作成の場合に警告または不許可としてもよさそうです。#LTA:ASIANB対策の提案のように）。ネイさんが指摘された「爵」の件ですが、LTA:203のリダイレクト作成荒らしで「爵」を含むことはあまりないように思います。方針・ガイドライン等（PJ合意も含む）で想定可能な事例として、不許可の対象外としてもいいのではないかと思います。--郊外生活（会話） 2019年11月23日 (土) 15:20 (UTC)
• 「曖昧さ回避」「公爵」「侯爵」「伯爵」「公」「侯」「伯」を例外とするは確定で良さそうですね。その他にプロジェクト単位での括弧についての取り決めなどがあればそれも含めるということでいきましょう。あまりに数が多ければまた別に考える必要がありそうですが、そこまで多くなければ一つずつ対応でなんとかなると思います。不許可については運用してみて問題なければくらいにしましょうか。初めから不許可にすると弊害となりそうな気がします。--そらたこ（会話） 2019年12月18日 (水) 18:54 (UTC)
• いまあがっているものの他に例外とした方が良いものはありますでしょうか。1週間ほどでなければ上にあるもののみ例外として確定にします。また、運用してみて後からでた場合議論なしで反映するものとして大丈夫でしょうか。--そらたこ（会話） 2020年1月7日 (火) 02:43 (UTC)

脚注がない記事の作成

提案中

目的

正しく働く脚注がない記事を検出する。

理由

出典を示すときは出典節に列挙するのではなく脚注を使って文章がどの出典に対応するか示す必要がありますが、脚注がない記事ではそれができていないと考えられます。出現率もかなり高く、特別:新しいページから100ページほど調べた結果、出典があるのに{{Reflist}}などがない記事が87記事（とさでん交通3000形電車、ネルンスト効果、1928年アムステルダムオリンピックのフランス選手団、1928年アムステルダムオリンピックのスウェーデン選手団、1928年アムステルダムオリンピックの南アフリカ選手団、雷弱児、スタニスラス・レピーヌ）、{{Reflist}}などがあるのに<ref>...</ref>がない記事が6記事（星稜vs済美延長13回、浅香庄次郎、海軍専門任務部隊、大谷温泉 (和歌山県)、Let's start now、LOVE×Quartet 2010）あります。 追記 <ref>...</ref>があるのに<references />がない場合でも警告が出ないようです（NeoForce母艦）。

--プログラム（会話） 2018年8月12日 (日) 09:20 (UTC) 一部追記。--プログラム（会話） 2018年8月16日 (木) 17:36 (UTC)

• <ref>...</ref>があり<references />がない記事については、Check WikipediaのID: 3として抽出されています。--aki42006（会話） 2018年9月8日 (土) 10:54 (UTC)

Lintエラーを発生させそうな編集への警告

提案中

目的	Lintエラーを発生させそうな編集に対して警告を出すことで、Lintエラーの発生を抑止する。
理由	Wikipedia:井戸端/subj/RemexHTML移行に関する合意形成で、Lintエラーのうち、廃止されたHTMLタグや閉じタグ漏れは、編集フィルターで抑止できるのではないかという話が出ました。今から編集フィルターを実装してもRemexHTML移行には間に合いませんが、移行後も廃止されたHTMLタグや閉じタグ漏れがあるのは望ましい状態とは言えません。この編集フィルターが実装されれば、Lintエラーを編集時にユーザに分からせることができるようになり、Lintエラーの低減につなげることができます。
発動条件	（Lintエラー全てを厳密に編集フィルターで拾うのは困難なため）、廃止されたHTMLタグや閉じタグ漏れがあった場合。
対処操作	警告（nowiki中の廃止されたHTMLタグを拾うfalse positiveなどの場合が考えらえるため）

-- MawaruNeko（会話） 2018年6月22日 (金) 17:04 (UTC)

すでにLintエラーがあった場合に、後続の編集者にエラーがずっと表示されてしまうことも考えらえるので、発動条件に「既存の編集になかった場合」を追加してもいいかもしれません。--MawaruNeko（会話） 2018年6月22日 (金) 17:04 (UTC)

コメント 現状30万件もある閉じタグ漏れに対して警告を出すのでは警告が多すぎるのではないかと思います。そのようなエラーがある程度修正される前はen:User:PerfektesChaos/js/lintHintなどのカスタムJSで何とかできませんか？--ネイ（会話） 2018年12月27日 (木) 12:32 (UTC)

コメント カスタムJSを導入するようなユーザであれば、ある程度閉じタグ漏れに対して注意を払っているかもしれません。また、現状の閉じタグ漏れの30万件のうち、かなりの部分は、テンプレートに閉じタグ漏れがあるのが原因であると予想しています。とはいえ、全て出すのは多すぎるというのはその通りだと思いますので、「既存の編集になかった場合」など、新規に閉じタグ漏れが発生した場合のみに警告を出すのはいかがでしょうか？ --MawaruNeko（会話） 2018年12月31日 (月) 10:54 (UTC)

ノートページでの除去

提案中

目的	ノートページで除去があった編集を検出する。
理由	他人の発言の改竄や、取り消し線を引くべき自分の発言の除去を発見しやすくするため。他人の発言を除去できるケースは同意があった場合と過去ログ化に伴う場合以外では限られており、自分の発言を除去する場合は基本的に取り消し線を引く方が良いため。Wikipedia:編集フィルター/提案/ログ/2011年#会話ページのコメントの除去の防止の再提案。同意がある場合でもタグ付けなら大きな問題にはならないと判断。
発動条件	ノートページで何らかの除去があった場合。
対処操作	タグ付け

--プログラム（会話） 2017年5月9日 (火) 08:02 (UTC)

私の一存では作成すべきか決められませんので、コメント依頼を提出いたしました。--ネイ（会話） 2017年10月21日 (土) 12:46 (UTC)

賛成 過去の利用者とのやり取りで会話ページの白紙化や発言除去が見られたため。--Licsak（会話） 2017年10月21日 (土) 14:22 (UTC)

では、2人以上の賛成があり、かつ反対がなかったため合意成立とみなします。ただし、発動条件の詳細についてお聞かせください：

1. 過去ログ化は除外しますか。除外する場合、どのような条件を想定していますか。
2. 「ノートページで除去があった」の判定条件は何を想定していますか。「removed_linesが空ではない」という条件では緩すぎると考えます。

以上です。--ネイ（会話） 2018年1月12日 (金) 14:20 (UTC)

返信 過去ログ化のみを抽出するのは難しいと考えているため、過去ログ化を含めて検出することを考えています。当初考えていた判定条件は「removed_linesが空ではない」でしたが単純な追加も検出してしまうので、複数行に書き加える頻度は低いと仮定する必要はありますが「removed_linesが複数行あるか、added_linesが空である」あたりでしょうか。--プログラム（会話） 2018年1月15日 (月) 14:02 (UTC)

コメント 2つ質問があります。

1. 意味を変える文字を挿入するなど、バイト数が増える形で荒らしがあった場合はその文字を除去しますが、フィルターだけ見ると荒らしを除去した人が荒らしをしているように見えてしまいますが、それは想定の範囲でしょうか。
2. 理由に他人の発言の改竄がありますが、検知するのは除去のみで、前の投稿と比べて増減なしの±0バイトになるような改ざん編集は検知しないのですか。

以上です。--duck775（会話） 2018年2月19日 (月) 14:31 (UTC)

1については「ノートページからの編集除去があった」という事実を意味するタグを付与するだけなので杞憂だと判断します。そのタグ付けで《荒らしを除去した人が荒らしをしているように見えてしまいます》というように見る人がいるとしても、そもそも現時点でも同様に（バイト数が減る時点で）荒らしをしているように見てしまうんじゃないかと。--iwaim（会話） 2018年4月10日 (火) 06:30 (UTC)

返信 コメントの改竄はできれば検出対象に含めたいと考えています。--プログラム（会話） 2018年9月16日 (日) 18:26 (UTC)

試験中のフィルター

数十万バイト以上の増減を許可しないフィルター

作成済

目的	荒らし防止
理由	最近100万バイト以上の文字列を追加する荒らしが多発しており、これを防ぐため
発動条件	編集者が拡張承認された利用者・スチュワードでなく、編集差分サイズの絶対値が一定値以上である編集（「名前空間が標準名前空間であること」の条件についてはおまかせいたします）
対処操作	不許可

最近[1], [2], [3]のように多量のコピペした文字列を投稿して楽しむタイプの荒らしが出現しています。これに対抗するための編集フィルターを提案します。なお、edit_deltaを絶対値で評価する理由としては、非拡張承認利用者による文字列の削除を認めつつ、その差し戻しは認めないというのは管理上問題はあると考えるためです。なお、記事の統合・分割・リダイレクト化など、有益な編集が阻害される可能性が必ずしも否定できないので、このフィルターによって編集が阻害された編集者に対する何らかの配慮は必要だと思います。 片割れ靴下（会話） 2020年5月1日 (金) 07:14 (UTC)一番上に移動--Q8j（会話） 2020年5月1日 (金) 07:20 (UTC)

• コメント まず、編集者についてですが、拡張承認者以外、ではなく自動承認以外、まで緩めていいと思います。その手の荒らしはおそらくWikipedia:進行中の荒らし行為#Jyoseisineほかだと思いますが、半保護突破はしないからです（少なくとも僕の知る限りでは）。ちなみに管理者は自動承認された利用者であれば自動的に昇格しますが、拡張承認された利用者には自動的にはならないので（自分自身で付与はできますが）仮に拡張承認に限るならスチュワードだけでなく管理者も対象外にする必要があります。バイト数は・・・うーん、仮に非自動承認を条件にするのであれば、10万バイトくらいでいいと思います。いくらWP:BOLDとはいえ、非自動承認者が10万バイトもの編集をするのは考えにくいのでは。方向性としては賛成です。さすがに誤検出はないでしょう、その条件じゃ・・・--Q8j（会話） 2020年5月1日 (金) 07:29 (UTC)
• 賛成 LTA化議論中の喉仏系荒らし対策ですね。100万バイト以上の意味不明な文字列追記は、環境によってはフリーズ等の原因になります（私自身、ArcGISを動かせるだけのスペックはあるPCを使用していますが、昨晩の荒らしの対処はかなり工夫しないと難しい状態でした。携帯端末だったら閲覧・編集よらずフリーズしたと思います）ので、あまりにもサイズの大きな増加（それも編集内容に有意性もない）は避けるべきだろうと考えます。Wikipedia:ページの分割と統合#分割の検討が29キロバイト以上のページで、特別:長いページも見る限りは、50万バイト以上（45ページ該当）か100万バイト以上（1ページ該当）の増減を不許可するという形なら、提案者ご指摘の巻き込まれのリスクは小さいかと思えます。--郊外生活（会話） 2020年5月1日 (金) 07:35 (UTC)
  • コメント まともな編集で50万バイトを超える増減の編集はほとんどないだろうと思って50万バイトとしましたが、数字には特にこだわりはありません。10万バイトでも悪くはないと思います（IP・新規利用者による10万バイト超の大幅加筆は珍しいと思いますが、ただ分割・統合、過去ログ化などで巻き添えを受けなければいいなと思います。50万バイト以上、としておくことで499,999バイト増減の荒らしを誘発しても困りますし、非公開フィルターにして、編集フィルター編集者さんが適切に設定してくださる形でもいいと思います。もし24番のフィルターの有効化・改良で対応できるならそれでも構わないと考えます。--郊外生活（会話） 2020年5月1日 (金) 09:13 (UTC)
• 情報 現在無効化されている24番のフィルターが今回ご提案の仕様に近いと思われます。非公開なので詳しい発動条件は分かりませんが。--本日晴天（会話） 2020年5月1日 (金) 08:02 (UTC)
  • 情報 本日晴天さんのとは別かと思いますが、参考までに:Wikipedia:編集フィルター/提案/ログ/2012年#10万バイト以上の編集を禁止（緊急措置）。私の10万バイトという意見はここを参考にしています。--以上の署名のないコメントは、Q8j（会話・投稿記録）さんが 2020/05/01 08:09 (UTC) に投稿したものです（Q8j（会話）による付記）。
  • 24番のフィルターが本件に転用できることを確認いたしました。とりあえず、フィルター名を20番の「サイズの大幅な増減」にならって「サイズの極めて大幅な増減」に変更しましたが、より適切な名称があればご提案いただければ幸いです。--ネイ（会話） 2020年5月1日 (金) 09:49 (UTC)
  • 報告 編集フィルター#24（変更履歴・一致記録）の対処操作を除去して、有効化しました。しばらく動作確認をしましょう。--ネイ（会話） 2020年5月13日 (水) 07:43 (UTC)
    • 1週間経過しましたが、その間に検出された10数件の編集は全て荒らしもしくはいたずらと言える編集であり、誤検出は見当たりませんでした。対処操作についてですが、不許可の際に表示するメッセージは既定のMediaWiki:Abusefilter-disallowedにしましょうか？--ネイ（会話） 2020年5月20日 (水) 14:22 (UTC)
      • 具体的な閾値が分からないので何とも言えませんが、ちょっと大き目な記事の分割・統合でも起こりえなさそうな値であるのならMediaWiki:Abusefilter-disallowedでもよいと思います。ほかの編集フィルタ―編集者の方の意見が欲しいところです。 片割れ靴下（会話） 2020年5月20日 (水) 17:20 (UTC)
• 対処 「不許可」の対処操作を付与して、MediaWiki:Abusefilter-disallowedを表示するようにしました。メッセージを変更すべきという方は仕様変更提案を提出していただけると助かります。--ネイ（会話） 2020年5月29日 (金) 04:38 (UTC)

利用者名に関係する記事の作成

作成済

目的	新規利用者が利用者名に関係する記事を作成しようとするとき、WP:AUTOの案内をする。
理由	Wikipedia:編集フィルター/提案/ログ/2018年#記事主題の利害関係者による編集の抑制の議論により、青子守歌さんの試験フィルター編集フィルター#4（変更履歴・一致記録）は利用者名と記事名が関連する編集を検出しています。そのログを見る限り、記事の新規作成はその利用者の最初の編集であることが多く、宣伝的な記事を検出できているようです。新規利用者による新規作成に限定すれば検出率を高く保ちつつ先行議論で指摘された問題点を解決できると考えます。
対処操作	警告、タグ付け
フィルター	編集フィルター#142（変更履歴・一致記録）

--プログラム（会話） 2019年2月10日 (日) 15:59 (UTC)

コメント ちょっと私生活に余裕が出たので改めて試験フィルターを見直しました。元の状態のログを見ても、それなりの記事が検出されており、発動対象の記事がCSDで削除済みのものも多く含まれており、どういう対処操作を付与するかにせよ、何かしら有用だとの意見は変わらず、活用できる方向に話が進むと良いなと思います。「新規利用者による新規作成に限定すれば」に加えて、2文字以下短すぎる文字列は明らかに範囲外にするのと、数字記事は除外すればかなり誤検出は防げると思います。警告による案内とタグ付けによる後で巡回でも十分な効果と思います。--青子守歌（会話/履歴） 2019年8月4日 (日) 04:08 (UTC)

賛成 票を付け忘れたので一応--青子守歌（会話/履歴） 2019年8月8日 (木) 01:09 (UTC)

賛成 その手の人物が警告くらいで投稿を引っ込めるとは思えませんが、とりあえず検出し易くするためにタグ付けだけでも有用だと思います。--Loasa（会話） 2020年4月1日 (水) 06:08 (UTC)　

@青子守歌さん: 試験中に移行してよいと考えますが、編集フィルター4番は現時点で青子守歌さんの試験フィルターとなっているため、移行をお願いできませんでしょうか？なお、移行する前に下記の修正を行うべきだと思いますが、非公開フィルターであるため一部詳細を伏せています。

• mw:Extension:AbuseFilter/Rules_format/jaで廃止予定とされる変数が使用されているため、移行先に修正すべきでしょう。
• 条件の3つ目を「新規利用者である」に修正する必要があります（詳しい条件は伏せます）。

@プログラムさん、青子守歌さん、Loasaさん: 警告文に盛り込むべき内容について、何かご意見はありますか？（編集フィルターで使用される警告文の一覧は特別ページにて閲覧できます）--ネイ（会話） 2020年5月6日 (水) 10:23 (UTC)

とりあえず編集フィルター#142（変更履歴・一致記録）にそのまま移植しました。廃止予定変数の修正以外は特に変更していませんので、このまま動作確認すると編集フィルター#4（変更履歴・一致記録）と同じような記録が取れると思います。--青子守歌（会話/履歴） 2020年5月6日 (水) 12:08 (UTC)

素早くご対応いただき、どうもありがとうございました。フィルター142番における3つ目の条件が「新規利用者」を正しく検出していないと思われますので、それを修正いたしました。--ネイ（会話） 2020年5月6日 (水) 12:19 (UTC)

コメント 試験中にして2週間程度経ちますが、一致記録を見てもらうと分かる通りかなりの精度で検出していて、しかもかなりの数であることが分かります。一致件数が現在で200件強なので、平均で15件弱/日です。同一投稿者がいるのでなんとも言えませんが、WP:AUTOを知らない人も多いでしょうから、彼らへの案内も含めて（警告）対処をつけるのが良いかと思います。メッセージ文を軽く下書きしました。

これを叩き台にして考えてみたら良いと思いますが、どうでしょう？（メッセージが必要かどうかも含めて）--青子守歌（会話/履歴） 2020年5月20日 (水) 14:01 (UTC)

質問なのですが、このような場合のノートページの稼働率（というか、有効に機能する割合）はどの程度なのでしょうか？ これまでにたくさん記事を書いてきて、または編集してきた私の肌感覚から言えば、必ずしもノートページは十分に機能しているわけではなく、放置されてしまっている投稿や提案も少なくないと思います。Wikipedia:連絡先/記事の問題/本人よりでは、メールアドレスによる問い合わせもありますから、これも追加してはどうでしょうか？ 片割れ靴下（会話） 2020年5月20日 (水) 17:31 (UTC)

深刻な法律侵害案件とかでない限り、OTRSに送られても結局「自分で編集するかノートで提案してくれ」で返信されて上記の説明と同じことになるので、ノートに書くようなことを連絡する先としてOTRSを追記しても無意味です（というか対応している人が少なすぎるのでむしろ遅れる可能性が高い）。しかし逆に言えば、ノートに書かれると後でWP:DP#Bで面倒になる話もあるわけなので、それを回避するための文言を追記しておく必要はたしかにありそうです。

その他リンクを少し加えました。--青子守歌（会話/履歴） 2020年5月21日 (木) 00:23 (UTC)

• ええと、タグ名は「利用者名に関係する記事の作成」「利用者名に関係する記事」それとも別の表記にしましょうか？--ネイ（会話） 2020年5月29日 (金) 04:44 (UTC)

1週間程度経過し特に反対やコメントもなかったので、フィルター#142の第2123版（差分）で対処操作を付与しました（メッセージは日本語がちょっと変だったのを直しました）。--青子守歌（会話/履歴） 2020年5月29日 (金) 05:06 (UTC)

仕様変更提案

CSSページで#57が発動しないようにする提案

TemplateStyleを利用する目的でTemplate:メインページ/test.cssを作成しようとしたところ、編集フィルター#57（変更履歴・一致記録）が発動しました。<!-- [[Category:○○○]] -->を記入することでカテゴリを付与することも一応可能ですが、基本的にCSSページにカテゴリは不要と考えます。つきましては、#57の発動条件に「.cssで終わるページ名でない」を追加することを提案します。--本日晴天（会話） 2020年6月24日 (水) 03:51 (UTC)

利用者ページの移動に対して編集許可できなくなった

Wikipedia‐ノート:編集フィルター#新規アカウントによる他者利用者ページの移動の条件についての対応をしていて気づいたのですが、（おそらく編集フィルター本体の機能の変更によって）移動操作の時に元のウィキテキストが取得できなくなっていました。つまり、編集フィルター#12（変更履歴・一致記録）で移動の時に、{{編集許可}}があるか判別できず、編集許可（この場合は移動許可）ができなくなりました。

代替方法がないので、完全に偽陽性を排除するためには、諦めて移動を防ぐのはやめる（移動は自由にする）しかないのですが、昨今の荒らし状況などから考えてもあまり有効ではないと思います。

ということで、仕様を変更（明記？）し、移動には編集許可は使えないようにしました。「新規利用者でも自由に移動してもらいたいような利用者ページは普通はないだろう」（編集ならともかく）という想定です。{{編集許可}}の説明文にも書いておきました。

以上、追認依頼を兼ねて記録しておきます。「実はこれなら解決できるよ！」という良い方法を見つけられた方は、修正いただけると助かります。--青子守歌（会話/履歴） 2020年3月8日 (日) 03:35 (UTC)

• @青子守歌: 代替方法はなく、苦肉の策なんですが「strpos(moved_from_recent_contributors,user_name) == 0」とかどうでしょう。僕の理解が正しければ、移動するページ（この場合利用者ページ）の最後の編集者が移動者と同じであればtrueになる・・・と思うんですが。{{編集許可}}使って、移動する人はそのページをテキトーに1回編集する。そしたらmoved_from_recent_contributorsの最初が編集者（＝移動者）になり、移動できる・・・はずです。まあ抜け道はできちゃうんですが・・・--Q8j（会話） 2020年7月28日 (火) 02:32 (UTC)

AllowEditの正規化

Wikipedia‐ノート:編集フィルター#「Template:Allowedit」の削除の是非について（編集フィルター12関係）で報告された問題です。{{AllowEdit}}に対してAlloweditと書いた人がいて、それでうまく動作しない（のでリダイレクトを削除すべき）という主張があったようです。

個人的には、ちゃんと{{編集許可}}のページにも書いてあるとおり、これは日本語がわからない人向けのテンプレートであり日本語を解する利用者が使うべきではない（素直に「編集許可」と書けば良い）というのと、かつ、MediaWiki:Abusefilter-warning-他利用者ページの編集での案内文にはちゃんとAllowEditと書いてあるわけで、これは単に「使い方を間違えている人が悪い」という気持ちしかありません。

とはいえ、まぁ別に対応するかどうか議論する時間がもったないほど対応は簡単で

• 大文字・小文字どちらでもよい(lcase)
• 途中に空白や改行が入っていても無視する(rmwhitespace)

すれば済みます。最後のは例えば

{{
allowedit}}

みたいなのを想定しています。まぁ副作用で

{
{al
        lowe
 dit}}

みたいなのも許可してしまうんですが、まぁ流石にそれは意図的にやってるとしか思えないので考慮しなくていいかなぁ・・・と（正規表現使ってもいいんですが、正規表現は重いので必要性がとても高いのでなければ極力避けたい）。

ということで、フィルター#12の第1858版（差分）で変更しましたので、その追認依頼も兼ねてここに残しておきます。もしもっと良い方法を思いついた方はぜひ修正をお願いします。--青子守歌（会話/履歴） 2019年11月17日 (日) 04:26 (UTC)

#47の「発動条件」と実装の相違

ネイさんが実装してくださった編集フィルター#47（変更履歴・一致記録）ですが、「Wikipedia:編集フィルター/一覧/Refタグつき記述の除去」の「発動条件」と実装に相違があると認識しています。このため、高橋まこと（ノート / 履歴 / ログ / リンク元）で実施された「発動条件」に合致するであろう編集で発動していません。

実装では閾値が設けられていますが、その理由は何でしょうか。--iwaim（会話） 2018年9月16日 (日) 03:12 (UTC)

現在の実装はen:Special:AbuseFilter/636を踏襲したもので、閾値があるのは英語版の実装にその閾値が設けられていることが理由となっています。提案者としては、閾値を除去しても残してもかまいません。--ネイ（会話） 2018年9月16日 (日) 03:40 (UTC)

英語版に閾値が設けられている理由が自分では見つけられなかったのですが、どこかに書かれているのでしょうか。個人的には閾値はなくてもいいと思います。--プログラム（会話） 2018年9月16日 (日) 18:26 (UTC)

返信 (プログラムさん宛) ネイさんは「編集フィルター#47（変更履歴・一致記録）に閾値が設けられている理由は、英語版の実装にその閾値が設けられていたからだ」と述べています。--iwaim（会話） 2018年9月19日 (水) 11:48 (UTC)

現状はプログラムさんが「個人的には閾値はなくてもいいと思います」と述べたほかには明らかな賛成票といえるコメントがありません。iwaimさんは提案者として賛成票を投じますか。または、ほかの方からのコメント/意見表明はありますか。（私からは棄権とさせてください）--ネイ（会話） 2018年12月27日 (木) 12:36 (UTC)

1年以上経過した本件についてですが、このまま放置しても仕方ありませんので、対処操作がタグ付けのみというのもあって、1週間後に閾値を除去したいと思います。--ネイ（会話） 2020年6月19日 (金) 03:46 (UTC)

対処 閾値を除去しました。--ネイ（会話） 2020年7月1日 (水) 16:02 (UTC)

対処操作「警告、不許可」の見直し

先日Wikipedia:お知らせのTech News: 2018-42で告知されたとおり、対処操作「不許可」のときエラーメッセージを選択できるようになりました。現状では、対処操作「警告、不許可」となっているフィルター（編集フィルター#5（変更履歴・一致記録）、編集フィルター#11（変更履歴・一致記録）、編集フィルター#12（変更履歴・一致記録）、編集フィルター#14（変更履歴・一致記録）、編集フィルター#40（変更履歴・一致記録））に引っかかった場合、警告を無視して編集しようとした際に一律でMediaWiki:Abusefilter-disallowedが表示されますが、これでは問題点についての説明を再び読むことができません。そこで、対処操作を「不許可」にしてエラーメッセージはそれぞれの警告メッセージを使うことを提案します。これなら不許可となるたびに個別のメッセージが表示されるので、2回目に問題点を解決しようとした場合に説明を読み直せます。--プログラム（会話） 2018年11月11日 (日) 06:40 (UTC)

賛成 プログラムさんが挙げたフィルター5件の変更に賛成します。これに合わせて、フィルター5番のコメントに「転送先がでカテゴリでない」という誤字がありますので、その修正も同時に行うことを提案します。--ネイ（会話） 2018年12月27日 (木) 12:49 (UTC)

提案者含め2人の賛成があり、反対がないため合意成立とみなすことができますが、提案者以外で唯一の賛同者であるわたしが対処することを避けたいので、ほかの編集フィルター編集者による対処を待つこととします。--ネイ（会話） 2019年1月14日 (月) 06:21 (UTC)

ネイさんご指摘のフィルター5番「C:で始まるが、 転送先がでカテゴリでない」ですが、ついでに前段も「CAT:で始まるが」とコメント、条件とも改めていただけますか。--Kurihaya（会話） 2019年1月30日 (水) 07:20 (UTC)

賛成 C:のままではフィルターの意味がなく有害なのでCAT:にすることに賛成します。--プログラム（会話） 2019年1月30日 (水) 18:16 (UTC)

賛成 Kurihayaさんの提案に賛成します。上記の通り、ほかの編集フィルター編集者による対処を待ちます。--ネイ（会話） 2019年2月7日 (木) 03:26 (UTC)

済 見落としていてかなり遅くなりましたが、フィルター#5の第2115版（差分）、フィルター#11の第2116版（差分）、フィルター#12の第2117版（差分）、フィルター#14の第2118版（差分）、フィルター#40の第2119版（差分）で「警告」を外して「不許可」のときにメッセージを表示するように変更しました。--青子守歌（会話/履歴） 2020年5月20日 (水) 14:55 (UTC)しました。

#2の対処操作

編集フィルター#2（変更履歴・一致記録）（ページの白紙化）は正式運用中ですが対処操作がありません。対処操作を「警告、タグ付け」として、警告文には即時削除や削除依頼の案内を入れたいと思うのですがいかがでしょうか。--プログラム（会話） 2019年1月4日 (金) 09:53 (UTC)議論ページへリンク--プログラム（会話） 2019年1月14日 (月) 04:48 (UTC)

• 賛成 正当な理由の白紙化より不当な理由(荒らしなど)での白紙化が多く、間に警告を入れることで誤った白紙化や白紙化荒らしの抑制に繋がると思います。--そらたこ（会話） 2019年12月7日 (土) 23:27 (UTC)
• タグ付けについては影響も少なく、荒らし対処に役に立つため 賛成 とし、警告については現時点で文案がないため保留とします。--ネイ（会話） 2020年5月5日 (火) 09:52 (UTC)
• 条件付賛成（条件：タグ付けのみ） なんの対処操作もないものは、何とかしなければと思いますし、タグ付けならそこまで影響もなく適切な白紙化をしている場合も編集できます。ただ、警告というと、いくら正当な白紙化より不当な白紙化の方が多いといったって正当な白紙化もあるわけですから警告まではしない方が良いのではないでしょうか。--Tmv（会話|投稿記録） 2020年5月13日 (水) 07:44 (UTC)

#2の廃止提案

対処操作をつけるという提案をしているところですが、私は廃止（無効化）を提案します（混じらないように節を切ります）。初期の頃に@Marine-Blueさんによって試験的に作られたもので、タグ付けはもうMediaWiki側でmw-blankタグ（タグが付与された最近の変更）として実装されているので、編集フィルターでやる意味がなくなりました。警告をつけるなら編集フィルターが必要ですが、議論ページを見てもらうと分かる通り、警告メッセージを入れることには慎重意見もあり合意形成できる気配はありませんでした。以上より、もう今では不要のフィルターです。--青子守歌（会話/履歴） 2020年5月20日 (水) 15:05 (UTC)

賛成 ping飛ばされたのでコメントしますが、私も積極的だったのは最初の頃だけです。正式化自体には賛成どころかコメントする気すらなくスルーしていました。なので、廃止されようとも一向に構いません。--Marine-Blue^{talk✿contribs❀mail} 2020年5月20日 (水) 15:58 (UTC)

大坂五人衆・明智五宿老のような事例もあるので、必ずしも無益だとは思いません。ただ、少数案件であれば、手作業で案内するということもできなくはないと思うので、↑のセクションを含め、特に賛否は示しません。 片割れ靴下（会話） 2020年5月20日 (水) 17:37 (UTC)

これ以上コメントがなければ、1週間後に無効化することを予告いたします。--ネイ（会話） 2020年6月4日 (木) 03:07 (UTC)

対処 無効化しました。--ネイ（会話） 2020年6月19日 (金) 03:31 (UTC)

#15の対処操作

編集フィルター#15（変更履歴・一致記録）（削除依頼テンプレートの除去）は正式運用中ですが対処操作がありません。対処操作を「警告、タグ付け」とすることを提案します。--プログラム（会話） 2019年1月4日 (金) 09:53 (UTC)議論ページへリンク--プログラム（会話） 2019年1月14日 (月) 04:48 (UTC)

以前の議論でも言及されているとおり、テンプレートを除去してよい場合（たとえば、削除依頼テンプレートを貼ったがサブページを作成しないまま放置した場合）もあるので、警告するのはもう少し慎重に行いたいと思います（警告文の内容にもよります）。一方、タグ付けに関しては行っても特に問題はないと思います。--ネイ（会話） 2020年5月5日 (火) 09:57 (UTC)

一部 対処 タグ付けのみ実施しました。--ネイ（会話） 2020年6月4日 (木) 03:04 (UTC)

@プログラム and ネイ: WP:EF/FPでの報告で気づいたんですが、これ「試しに作ってみた」が実装内容や対処操作をどうするかなどの合意や議論を経ずに放置されたままのがいつの間にか「正式運用」になってしまって、#提案から正式稼動までの流れに違反していたものなのですね（cf. Wikipedia:編集フィルター/一覧/削除依頼テンプレートの除去）。操作がタグ付なのであまり大きな影響はないですが、誤作動の報告もあることですし、対処操作付けの提案＆実施はちょっと誤りだった（先にやるべきことがもっとあった）のではないかな、と思います。差し戻せ、というわけではもちろんないですが、気づいたことのコメントだけとりあえず。--青子守歌（会話/履歴） 2020年7月21日 (火) 15:08 (UTC)

うーん、誤作動の修正提案のついでに、正式稼働の追認提案も行うのはどうでしょうか。--ネイ（会話） 2020年7月21日 (火) 15:41 (UTC)

#20を公開する提案

編集フィルター#20（変更履歴・一致記録）（大きなサイズの増減）は非公開フィルターですが、閾値を推定するのが難しくなく編集を防ぐわけでもないので非公開にする意味がなく、むしろ非公開になっていることで改良しにくくなっているように思われます。このフィルターを公開することを提案します。--プログラム（会話） 2019年1月14日 (月) 04:48 (UTC)

フィルターの提案者である青子守歌氏からコメントをいただければと思います。わたしからの賛否表明は今のところはありません。--ネイ（会話） 2019年1月14日 (月) 06:26 (UTC)

コメント 今となってはどちらでも良いと思います。改良というほど複雑ではないですし、当時は対荒らしの参考用フィルターという期待が強かったので非公開にしようという話だったような？--青子守歌（会話/履歴） 2019年1月17日 (木) 23:46 (UTC)

では、これ以上コメントがなければ1週間後に公開に切り替えます--ネイ（会話） 2020年5月5日 (火) 09:51 (UTC)

済 公開しました。--ネイ（会話） 2020年5月13日 (水) 07:37 (UTC)

#49の仕様変更について

編集フィルター#49（変更履歴・一致記録）（利用者ページのルール告知）について、Wikipedia:井戸端/subj/利用者ページのルール告知する編集フィルターについてで提案したことを提案します。具体案としては、MediaWiki:Abusefilter-warning-利用者ページのルール告知にあるWikipedia:利用者ページ、Wikipedia:記事の所有権、Wikipedia:ウィキペディアを二次利用する、Wikipedia:利用者ページの削除依頼、Wikipedia:即時削除の方針のいずれかまたはいくつか、もしくは全部、あるいはTemplate:User Wiki-3、Template:User Wiki-4のユーザーボックスなどのリンク貼り付けで除外する案も考えています。何らかの条件で利用者ページフィルターの除外対象にするのを提案します。--210.248.148.151 2019年11月28日 (木) 06:11 (UTC)

おそらく個々の具体案に分割して頂いたほうがいいと思います。それぞれに賛否があると思いますよ。--遡雨祈胡（会話） 2019年12月4日 (水) 04:54 (UTC)

提案者です。自分で提案しといてなんですが、どのように分けようか分からなくなってしまって、返事が大変遅れてしまいました。直近のWikipedia:井戸端/subj/拡張半保護の導入（再提案）あたりを参考にしたいと考えているところです。--210.248.148.147 2020年5月2日 (土) 13:41 (UTC)

分割方法に大変悩みましたが、
①Wikipedia:利用者ページ

②Wikipedia:記事の所有権

③Wikipedia:ウィキペディアを二次利用する

④ Wikipedia:利用者ページの削除依頼

⑤Wikipedia:即時削除の方針

⑥Template:User Wiki-3

⑦Template:User Wiki-4
に上記の案を分割します。これらのいずれかまたはいくつか、もしくは全て賛成、反対の方は各番号を示した上で表明をお願いします。また、新たに提案ある方はコメントお願いします。--210.248.148.153 2020年6月17日 (水) 15:06 (UTC)

ちょっとまだ投票は決めかねています。確認させて頂きたいのですが、User Wiki-2から下のものが入っていない理由を伺っても宜しいですか。--遡雨祈胡（会話） 2020年6月21日 (日) 05:32 (UTC)

Template:User Wiki-0は初心者の可能性があり、判断に入れませんでした。Template:User Wiki-1、Template:User Wiki-2は考えましたが、ウィキペディアの編集に第一に役立つとはいえども、利用者ページのルールには直接関係がなかったので、入れるとしたら3と4が確実だと考えました。3と4を入れたのは、わざと利用者ページで問題を起こす人を除いて、3と4に該当する人で問題を起こした人を見たことがなかったからです。--210.248.148.147 2020年6月22日 (月) 15:55 (UTC)

すみません、間が空きました。正直この手のものは自称なのであまり「User Wiki-X」のくだりは信用しないほうがいいような気がしておりますが、何ともしがたいですね。一旦置いておくことにします。--遡雨祈胡（会話） 2020年7月11日 (土) 13:20 (UTC)

そうですね、調べたら利用者ページの理解してない方は見つかっていませんが、無期限ブロックになった方はいました。一方で実際有益な編集をよくされる方はいるのは確かなので、取り下げまではしませんが、直接関係のあるWikipedia空間のページを中心に考える方向で話が進めればと思います。--210.248.148.153 2020年7月12日 (日) 10:28 (UTC)

優先度は1-5が高く、6-7が低いということでしょうか。--遡雨祈胡（会話） 2020年7月25日 (土) 16:54 (UTC)

質問の意図が伝わらず、良くない質問ですね。すみません。意図としては、IP利用者さんにとっての優先度がどんな感じなのかが伺いたいです。--遡雨祈胡（会話） 2020年7月25日 (土) 16:56 (UTC)

ご指摘の通り1-5の優先度を高く見積もっています。--210.248.148.149 2020年7月27日 (月) 16:05 (UTC)

• コメント 私の読み間違いなら申し訳無いですが「もしくは全部、あるいはTemplate:User Wiki-3、Template:User Wiki-4のユーザーボックスなどのリンク貼り付けで除外する案も考えています。」というのは、告知文を貼り付ける代りに「User Wiki-X」のユーザーボックスを貼り付ける、という意味ですよね。告知文の一部除去についてはわかるのですが、代替として「User Wiki-X」のユーザーボックスを貼り付けるという提案の意図がさっぱりわかりません。御手数ですが、ユーザーボックスを貼り付けるということの意味というか意図をご説明いただけませんか。--Loasa（会話） 2020年7月27日 (月) 21:04 (UTC)

編集履歴によく利用者ページを作る方はいますし、有益な編集する方法を熟知してるなら、ログイン時に表示される利用者のページの作り方ぐらいは把握してるだろうと思い、User wiki-3-4の提案をしていました。少し調べましたが、3-4の方に、実際にベテランで編集方法を理解されてる方はいました。無期限ブロックとなった方も中にはいましたが、利用者ページで問題起こした方は私が知る限りいませんでした。今は自称で実と異なる可能性があるとの指摘を受け、このユーザーボックス提案を後回しにするか取り下げるか迷っているところです。--210.248.148.147 2020年7月29日 (水) 11:29 (UTC)

#5にPJT:を追加する

編集フィルター#5（変更履歴・一致記録）（不適切なショートカットの作成）についてですが、Wikipedia‐ノート:ショートカット#プロジェクト・ノート用のショートカット接頭辞についてによりプロジェクト‐ノート名前空間用に「PJT:」の接頭辞が追加されたため、これに伴う修正を行いたいと思います。具体的には「PJT:で始まるが、 転送先がプロジェクト‐ノート名前空間でない」場合を検出するように変更したいと思います。--ネイ（会話） 2020年5月6日 (水) 10:29 (UTC)

• 賛成 ついでに2行目のcの部分をcatに置き換えた方がいいでしょう（1行目のコメントも同様）。18・26行目については#対処操作「警告、不許可」の見直しでの変更の際に修正されましたが、1・2行目については修正が漏れているようです。--本日晴天（会話） 2020年6月1日 (月) 12:23 (UTC)
  • 済 上記わたしと本日晴天さんが提案した変更を実施しました。また、提案にはありませんが、Wikipedia‐ノート名前空間には「Wikipedia talk」という別名があるので、それも許可するよう修正しました。--ネイ（会話） 2020年6月4日 (木) 03:02 (UTC)

#26の無効化

編集フィルター#26（変更履歴・一致記録）（LTA対策）についてですが、作成以降対処操作が付与されたことはなく、また当該LTAが数年前より活動を休止したためか近年では1年に0から1件が検出される程度となっています。つきまして、当該フィルターの無効化を提案いたします。--ネイ（会話） 2020年5月6日 (水) 10:36 (UTC)

• 賛成 必要になればまた有効化もありですが、年間１件あるかないか、といったものにログづけする、というフィルターに負荷に見合う効果を見出すことができません。無効化に賛成します。--Q8j（会話） 2020年5月7日 (木) 00:25 (UTC)
  • 済 無効化しました。--ネイ（会話） 2020年5月20日 (水) 14:16 (UTC)

ログ

• Wikipedia:編集フィルター/一覧 - 正式運用中のフィルターの一覧と議論の過去ログ
• Wikipedia:編集フィルター/提案/ログ - 正式運用に至らなかったフィルターの議論の過去ログ