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

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

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

提案と作成

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

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

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

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

新しく提案するには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログ化

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

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

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

提案中のフィルター

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

提案中

目的	荒らし防止
理由	最近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)
• 情報 現在無効化されている24番のフィルターが今回ご提案の仕様に近いと思われます。非公開なので詳しい発動条件は分かりませんが。--本日晴天（会話） 2020年5月1日 (金) 08:02 (UTC)
  • 情報 本日晴天さんのとは別かと思いますが、参考までに:Wikipedia:編集フィルター/提案/ログ/2012年#10万バイト以上の編集を禁止（緊急措置）。私の10万バイトという意見はここを参考にしています。

移動荒らし対策 

提案中

目的	移動荒らし差し戻し
理由	移動荒らしがされた後、移動元ページが編集されると管理者、削除者以外の差し戻しができなくなります。それを阻止するためのフィルターです
発動条件	作成から10分以内（page_ageが600未満）、かつリダイレクトページを編集回数100回未満の利用者が編集、移動しようとした時
対処操作	不許可

微修正--Q8j（会話） 2020年3月16日 (月) 08:01 (UTC) 今日出現した利用者:永野由祐（会話 / 投稿記録 / 記録）は移動荒らしをした上でリダイレクトページを上書きするという手法で荒らしました。あまりにページが多岐にわたり、その後処理が20分かかりました（対処されたのはNnhさんです）。このフィルターにより、リダイレクトページの編集を防ぎ、差し戻しをしやすくする（これであれば移動=自動承認者であれば差し戻し可能）ことを目的としています。--Q8j（会話） 2020年3月16日 (月) 07:56 (UTC)節名付与--Q8j（会話） 2020年5月1日 (金) 07:20 (UTC)

会話ページの移動荒らし防止

提案中

目的	移動荒らし防止
理由	同上
発動条件	管理者以外の利用者が、他者の会話ページを移動しようとしたとき
対処操作	不許可

最近多発しているLTA:SZMYによる荒らしを防ぐことを目的としています。「他者の」の判定基準は分かりませんが、他者の利用者ページ編集防止があるのなら多分できる・・・と思います（出来るでしょうか？）。自分以外の会話ページの移動が必要になる状況はちょっと思いつきませんが、一応管理者は対象外でいいと思います（なんかで必要になるかも？）-- Q8j（会話） 2020年3月6日 (金) 05:36 (UTC)

• コメント 編集フィルターを実装するとしても管理者・削除者は対象外にすべきと考えます（編集フィルターにより特定版削除ができなくなるおそれがあるので）。あと、利用者名変更のときの移動はあるので、スチュワードとグローバル利用者名変更者（m:Global renamers）についても対象外にすべきです。あと、時々本人から依頼があって会話ページの過去ログ化を代行することはあります（例: 利用者‐会話:利用していないアカウント（履歴 / ログ / リンク元））。このときは状況を踏まえて固定版リンク方式で行いましたが、状況によっては移動方式のほうがよい場合もあるかと思います。確かに過去ログ化は少々複雑で、慣れていない方、モバイル編集で参加している方には難しいところもあります。これらの操作を管理者に代行してもらうと管理者の負担も大きくなりますし、固定版リンク方式が必ずしも最適とも限らないので、1年以上500回編集とか、条件を緩めてもいいのではないかと思います。もしくは、LTA:SZMYがよく使用している糞尿関係の用語、性器関係の用語を新規アカウントが書き加えた場合に編集フィルター（不許可）をかけてしまうというのもあるとは思います（設定次第では編集にも移動にもフィルター対象にできるかもしれません。また、滋賀県警察（ノート / 履歴 / ログ / リンク元）での荒らし対策でも使えると思います）--郊外生活（会話） 2020年3月6日 (金) 05:59 (UTC)
• フィルター#12の条件を丸ごと流用して会話ページの移動のみを規制すれば良いと思います。フィルター#12の改造で対応出来るような気もしますが、条件式についてよく覚えてないのでどなたか助言を頂ければ。--Marine-Blue^{talk✿contribs❀mail} 2020年3月6日 (金) 07:14 (UTC)
  • 返信 (郊外生活さん宛) であれば、拡張承認された利用者（成立すればですが）をまとめて対象外にするほうが楽かもしれません。条件は郊外生活さんの仰ったものとほぼ同じですし、その条件を満たしてそんな低レベルな荒らしを行うことは考えにくいですし（編集フィルターはサーバーに負荷がかかると言うことなので、条件式は可能な限りシンプルにしたいです）。削除者、管理者が500回未満で信任されるとは考えにくいですが、その場合は拡張承認を権限付与するBCが手動で付ければ済みます。糞尿関係などのNGワードは良いとは思いますが、どうせイタチごっこになるだけなので、私の提案には含めません（もちろん郊外生活さんが別途提案されるのであれば賛成しますが）。グローバル関係ですが、現状かかっている新規利用者による他者利用者ページの編集禁止フィルターは2010年から有効ですが、グローバルリネーマーのMaximさんは初編集から利用者名変更に伴う移動を使っておられるので、多分大丈夫・・・かな？（現状のフィルターは既にグローバルリネーマー対策もしてるんでしょうか？--Q8j（会話） 2020年3月6日 (金) 07:30 (UTC)
    • 返信 拡張半保護が運用開始されれば、その条件でいいと思います。確かに拡張承認条件を満たしていない管理者・削除者というのは考えにくいです（管理者権限つきbotとかは別ですが）し、必要があれば個別に拡張承認させればいいと思います。Marine-Blueさんが提示されている編集フィルター12ですが、その数値でも悪くはないと思います。ただ、直近で利用者:令和の猫好き（会話 / 投稿記録 / 記録）（LTA:SZMYの善玉アカウントの疑い）が2020-01-06にアカウントを作成した後、2020-01-18（12日後）に編集回数500回くらいのところで他者利用者ページの作成を行っていることを考えると、基準（おそらくアカウント作成日からの日数）を厳しくした方がいいのではないかとも思えなくはないところです。--郊外生活（会話） 2020年3月6日 (金) 08:58 (UTC)
      • 返信 (郊外生活さん宛) @Marine-Blueさん: ああ、すみません。編集回数500回と言うご提案を見て、拡張承認とほぼ同じと申し上げたのですが、日数が重要とのことであれば、日数指定を行うのもありだと思います（元々管理者・本人以外不要と考えていた立場でもありますし）。日数は別に意見はないので（活動期間1年未満の管理者削除者は考えにくい）、郊外生活さんが1年とおっしゃるなら1年にします。そうなると提案は結局、「活動期間1年未満、もしくは編集回数500回未満の（スチュワード・グローバル利用名変更者以外の）利用者が他者会話ページ、そのサブページを移動しようとしたときに不許可」（括弧内は必要であれば（このフィルターが利用者名変更に伴う自動移動を阻害するなら）、です）、と言うことになりますかね？（サブページは私が今独断で付け加えました。過去ログの移動荒らしも理論上あるわけですし、お二人に異論がなければ。）--Q8j（会話） 2020年3月6日 (金) 11:33 (UTC)
        • コメント 1年間というのは編集フィルター#49（変更履歴・一致記録）をの数値から引っ張っています（Wikipedia:編集フィルター/一覧#初心者向け案内にもリストアップされていますし）。数ヶ月でも構わないと思いますし、拡張半保護の数値とあわせればいいようには思ったのですが（「令和の猫好き」アカウントも編集できないですし）、まだ3ヶ月か4ヶ月か決まっていませんし、それならフィルター49にあわせてでいいのかなと思いました。今後、拡張半保護の数値が確定したらそれに変更してもいいと思います。1年を超えたら長すぎかなとは思いますが、1年間は少し長いけれど許容範囲の上限かなと思います。提案のまとめですが、「不許可」でいいと思いますし、サブページも対象にして良いと思います。会話ページの過去ログを荒らす事例も少なからず見かけます（特に会話ページが半保護されている場合。利用者‐会話:わたらせみずほ/過去ログ1（履歴 / ログ / リンク元）など）ので、除外する理由はないと思います。--郊外生活（会話） 2020年3月6日 (金) 13:25 (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)

移動荒らし防止

提案中

目的	移動荒らし防止
理由	同上
発動条件	Wikipedia名前空間で、登録してから60日、編集回数500回を満たさないユーザーが移動しようとした時
対処操作	不許可

履歴分離では移動の必要はありますが、この発動条件であればその邪魔にはなりづらいのかな、と思います。 --Q8j（会話） 2020年2月1日 (土) 01:32 (UTC)

• その発動条件では影響が大きすぎるのでは？--ネイ（会話） 2020年4月29日 (水) 07:57 (UTC)

ブロック依頼における荒らし・改竄防止

不作成

目的	投稿ブロック依頼にて、コメント、投票資格のないものによるコメントを防ぐ
理由	資格のない人のコメントだから防ぐというより、荒らしがブロック依頼にて沸くことが多いように思います。このフィルターによりその手の荒らしを抑制し、また終了後の依頼サブページの改竄も減らせると考えます。
発動条件	「Wikipedia:投稿ブロック依頼/」から始まるページで、投稿回数50回未満、または活動期間1ヶ月未満の利用者が編集した時
対処操作	不許可

また、資格を満たさずとも被依頼者のコメントは認められていることより、「{{編集許可}}」のようなtemplate（というより基本表示させる必要はないため、既存のhidden=1を流用もできると思います）を貼り付けたページはそのフィルターの適用外とする、という条件で考えています。如何でしょうか。 -- Q8j（会話） 2020年1月4日 (土) 00:32 (UTC)

• 取り下げ 最近この手の事例を見かけなくなったので、取り下げます。--Q8j（会話） 2020年3月20日 (金) 16:35 (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)

フィルターの名前

不作成

目的	権限を保持しない利用者が{{user admin}}等を貼付できないようにする。
理由	散発的 (diff/73774241, diff/73439235など) にこのタグを使った荒らしが発生するため。
対処操作	不許可

-- eien20（会話） 2019年8月10日 (土) 02:12 (UTC)

• （反対）わざわざフィルターを作成するほど頻発していない。記事にも影響が少なく低規模。--126.255.142.144 2019年10月22日 (火) 05:16 (UTC)
• 提案 それらテンプレート（{{User admin}}）が貼り付けられたページにカテゴリーを付与するというのはどうでしょう？それならそのページを誰かが巡回すれば濫用してる人に気付けると思います。現時点でフィルターをつけるまでのことはしなくていいのかなぁ、と思います。「確認」リンクもついてますし。--Y.iwamoto-0810（会話） 2019年11月19日 (火) 13:40 (UTC)撤回--Y.iwamoto-0810（会話） 2019年11月20日 (水) 14:18 (UTC)
  • カテゴリをつけるもなにも既にCategory:ウィキペディアの管理者がついています。
• 反対 定期的にカテゴリを見ていますが、そこまで頻繁には起こっていません。--そらたこ（会話） 2019年11月20日 (水) 13:55 (UTC)
  • • 返信 ほんとだ・・・お恥ずかしい。撤回します。--Y.iwamoto-0810（会話） 2019年11月20日 (水) 14:18 (UTC)
• 反対 改めて。確認リンクもついてることですし、現状不必要かなと思います。まあ仮に権限がないのにそれを付けてるユーザーが居たとして、それに騙される人は少ないでしょう。その利用者ページを訪れる人が多ければ、テンプレートの不正利用に気づく人もいるはずですし。確認リンクは、例えばsubstして書き換える（自分と名前が似ている管理者にしてしまう）とかされると無力ですが、それならカテゴリーも編集フィルターも無駄ですしね。--Y.iwamoto-0810（会話） 2019年11月20日 (水) 14:18 (UTC)
• 却下 作成しないことで合意が形成されたとみなします。--ネイ（会話） 2020年4月1日 (水) 03:35 (UTC)

LTA:ASIANB対策

提案中

目的	LTA:ASIANBによる大量のカテゴリ置換作業を抑止する。
理由	このところLTA:ASIANBのソックパペットが、プロジェクト‐ノート:映画/過去ログ6#各国の男優・女優カテゴリについてでの合意を無視したカテゴリ編集（例1、例2）を長時間にわたり繰り返し、管理者がブロックするまでの間に何百もの記事が被害を受けるという事態が繰り返されています。編集フィルターを用いてこのようなカテゴリ置換作業を抑止できれば、編集の差し戻す手間を軽減できると考え、新たなフィルターの作成を提案します。善意のユーザーによって性別不明や性的少数者の俳優記事に対してカテゴリを置き換えるような編集が行われる可能性も考慮し、提案する発動条件には編集頻度も含んでいます。
発動条件	あるアカウントが「Category:○○の男優」もしくは「Category:○○の女優」を「Category:○○の俳優」に置き換える編集をある頻度（例えば1分間当たり1編集）を超えて繰り返し行った場合に発動する。
対処操作	不許可

--本日晴天（会話） 2019年3月15日 (金) 13:00 (UTC)

賛成 編集速度が高く、被害が大きくなりがちなLTAなのでフィルターで減速させることで被害を最小限にできると考えます。--プログラム（会話） 2019年3月15日 (金) 14:12 (UTC)

取り下げ ここしばらくは上記の大量投稿が見られないため提案を取り下げます。--本日晴天（会話） 2020年5月1日 (金) 08:07 (UTC)

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

提案中

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

--プログラム（会話） 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)　

不適切な利用者名の疑い

提案中

目的	不適切な可能性の高い名前のアカウントの作成を検出する。
理由	不適切な利用者名の報告は少なくなく、コミュニティの負担になっているように見えます。タグを付けることによって効率的に探すことができるようになり、コミュニティの負担を軽減できると考えます。
対処操作	タグ付け

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

「不適切な名前のアカウントの編集」の検出を想定するとして、アカウント名の検出にどのような条件を想定していますか。--ネイ（会話） 2019年3月15日 (金) 15:49 (UTC)

action == "createaccount" & (length (accountname) > 20 | contains_any (norm (accountname), 管理者のアカウント名1, 管理者のアカウント名2, …, 管理者のアカウント名n))のような条件を考えています。アカウント名が文になっているとき不適切な名前であることが多いため、長いアカウント名を検出対象にしています。--プログラム（会話） 2019年3月17日 (日) 12:43 (UTC)

「不適切な利用者名の疑い」のタグだと、つけられる時点で不名誉な感じになってそうなので、長いだけでつけるのはあまりよくないと感じます（別に方針などで禁止されているわけでもありませんし）。管理者のアカウント名を含む場合については、miyaさんやわたしの利用者名で誤検出が多数になると予想しています。--ネイ（会話） 2019年11月20日 (水) 16:10 (UTC)

コメント じゃあそのまま「管理者名を含む長い名前」とかどうでしょうか。後思ったのですが、このフィルターで想定しているアカウントって[4][5][6]こういうやつですよね？だとすれば20以上は少々緩すぎではないでしょうか？そもそも直近24時間で作られたアカウントが（ざっと作成ログを500件表示にして確認したところ）4、500くらいで、管理者名含むアカウントなんてそうそう作られないと思うので、いっその事全検出（管理者名含むアカウントを文字数にかかわらず検出）でもいいと思うんですが・・・。別にタグをつけるだけで、自動ブロックされるわけでもないでしょうし。そしてタグを「管理者名を含むアカウント作成」とでもすれば、ネイさんがおっしゃった「付けられる時点で不名誉」問題も解決されるのでは。--Y.iwamoto-0810（会話） 2019年11月21日 (木) 00:39 (UTC)

タグ名を「管理者名を含むアカウント作成」にすることで「付けられる時点で不名誉」の問題が解決されるという考えに同意します。利用者名の長さの閾値については特に意見はありません。--ネイ（会話） 2019年11月23日 (土) 14:32 (UTC)

コメント 管理者名を含む名称を検出する、というのは一つの考えだと思いますし、それで対応可能なこともあると思います。しかし、管理者名と酷似するアカウント名は検出できません。荒らしとしてブロックされたアカウントで「BeIlcricket」（3文字目が大文字アイ）があり、このページを見ている方であれば管理者名と酷似することはわかるかと思います。タグを回避するために、少しだけアカウント名を変えるような事例が起こりそうな気がします（特にLTA案件。先のアカウントは投稿傾向からLTA:IKEのように思いますが、当該LTAは既存利用者と類似する不適切な利用者名での荒らし行為がよくあります: 管理者ではありませんが「NickeI 2 Train」（6文字目が大文字アイ）、「夕ーナーチュウ」（一文字目が夕方の「夕」）といったアカウント名もみられます）。「管理者名を含む名称を検出する」のが本当に有効なのかというと疑問が残ります。この件についてはどうお考えでしょうか。--郊外生活（会話） 2019年11月23日 (土) 15:08 (UTC)

利用者:ラブライブサンシャインが招いたアールセックスワイの辞任のように管理者の名前を、本来の文字種から変更したり、名前の一部を変更したりという手段で容易に回避でき、ウィキペディアを熟知した荒らしへの対応力が低いと思います。そしてrxyだけでなく「アールエックスワイ」も検出とか「あーるえっくすわい」も検出とか、1-2文字違いも検出とか色々条件を付け加えれば付け加えるほど、保守性が低下し、コストの高い編集フィルターになってしまうと思います。あまり有効に機能しそうにないため、反対します。 片割れ靴下（会話） 2020年4月27日 (月) 02:17 (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)

試験中のフィルター

現在、試験中のフィルターはありません。

仕様変更提案

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

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

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

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

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

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

先日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)

#2の対処操作

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

• 賛成 正当な理由の白紙化より不当な理由(荒らしなど)での白紙化が多く、間に警告を入れることで誤った白紙化や白紙化荒らしの抑制に繋がると思います。--そらたこ（会話） 2019年12月7日 (土) 23:27 (UTC)

#15の対処操作

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

#20を公開する提案

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

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

コメント 今となってはどちらでも良いと思います。改良というほど複雑ではないですし、当時は対荒らしの参考用フィルターという期待が強かったので非公開にしようという話だったような？--青子守歌（会話/履歴） 2019年1月17日 (木) 23:46 (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:編集フィルター/一覧 - 正式運用中のフィルターの一覧と議論の過去ログ
• Wikipedia:編集フィルター/提案/ログ - 正式運用に至らなかったフィルターの議論の過去ログ