コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「Wikipedia:編集フィルター/提案」の版間の差分

削除された内容 追加された内容
44行目: 44行目:
*すなわち、私の理解が正しければ、Taisyoさんが作成しようとしている編集フィルターは技術上可能であると思います。--[[利用者:ネイ|ネイ]]([[利用者‐会話:ネイ|会話]]) 2020年4月1日 (水) 13:01 (UTC)
*すなわち、私の理解が正しければ、Taisyoさんが作成しようとしている編集フィルターは技術上可能であると思います。--[[利用者:ネイ|ネイ]]([[利用者‐会話:ネイ|会話]]) 2020年4月1日 (水) 13:01 (UTC)
::忙しくなったのと、仕様理解に苦労していたので返事が遅れました。とは言いつつも理解し切れていません。処理負荷を考慮しなければ、かなり細かく見ることが出来るみたいですが、負荷の大きい仕様は良くないと思います。仕様を端折るなどして、比較的低負荷なフィルターの構築をお願いしたいと思います。--[[利用者:Taisyo|Taisyo]]([[利用者‐会話:Taisyo|会話]]) 2020年4月12日 (日) 13:19 (UTC)
::忙しくなったのと、仕様理解に苦労していたので返事が遅れました。とは言いつつも理解し切れていません。処理負荷を考慮しなければ、かなり細かく見ることが出来るみたいですが、負荷の大きい仕様は良くないと思います。仕様を端折るなどして、比較的低負荷なフィルターの構築をお願いしたいと思います。--[[利用者:Taisyo|Taisyo]]([[利用者‐会話:Taisyo|会話]]) 2020年4月12日 (日) 13:19 (UTC)
* これ以上編集できなくなるという回数が3回目以降の連続編集のたびに表示され、善意によるプレビュー不使用編集に対応することを条件に賛成します。わかりやすく言えば、「同一利用者が、1時間以内に5回同一ページを編集した時、6回目の同一ページ編集を不許可とする」という編集フィルターを作る場合、3回目の編集の時は、「ウィキペディアへの過剰負荷防止と荒らし防止の観点から、可能な限りプレビュー機能を利用するようにしてください。◯◯分以内にあと2回このページを編集すると、このページへの編集ができなくなります。」と表示され、4回目の編集の時は前掲メッセージにおいて「あと2回」を「あと1回」に置き換えたものが表示され、というように悪意でない編集に対してプレビュー機能の利用を促すことで、善意の利用者に対する啓発や対策をすることが必要だと思います。 [[利用者:片割れ靴下|片割れ靴下]]([[利用者‐会話:片割れ靴下|会話]]) 2020年4月27日 (月) 02:04 (UTC)


=== 移動荒らし防止 ===
=== 移動荒らし防止 ===

2020年4月27日 (月) 02:04時点における版

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

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

提案と作成

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

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

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

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

新しく提案するには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログ化

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

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

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

提案中のフィルター

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

微修正--Q8j会話) 2020年3月16日 (月) 08:01 (UTC) 今日出現した利用者:永野由祐会話 / 投稿記録 / 記録は移動荒らしをした上でリダイレクトページを上書きするという手法で荒らしました。あまりにページが多岐にわたり、その後処理が20分かかりました(対処されたのはNnhさんです)。このフィルターにより、リダイレクトページの編集を防ぎ、差し戻しをしやすくする(これであれば移動=自動承認者であれば差し戻し可能)ことを目的としています。--Q8j会話2020年3月16日 (月) 07:56 (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-Bluetalkcontribsmail 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:ASPELTA:203LTA:Iccicなどで、半保護突破を目的とした編集数稼ぎが多く発生しています。実現可能なものから早期に実装し、必要に応じて随時拡張をお願いしたいと思います。--Taisyo会話2020年2月2日 (日) 03:46 (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)[返信]

移動荒らし防止

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

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

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

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

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

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)[返信]

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

提案中 提案中
目的 新規利用者が利用者名に関係する記事を作成しようとするとき、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)[返信]
コメント じゃあそのまま「管理者名を含む長い名前」とかどうでしょうか。後思ったのですが、このフィルターで想定しているアカウントって[1][2][3]こういうやつですよね?だとすれば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)[返信]

脚注がない記事の作成

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

--プログラム会話) 2018年8月12日 (日) 09:20 (UTC) 一部追記。--プログラム会話2018年8月16日 (木) 17:36 (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)[返信]

#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-3Template:User Wiki-4のユーザーボックスなどのリンク貼り付けで除外する案も考えています。何らかの条件で利用者ページフィルターの除外対象にするのを提案します。--210.248.148.151 2019年11月28日 (木) 06:11 (UTC)[返信]

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

ログ