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

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

提案と作成編集

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

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

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

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

新しく提案するには編集

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログ化編集

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

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

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

提案中のフィルター編集

LTA対策 (アガリYAYURE新川温泉の対策)編集

  提案中
目的 自動承認された利用者以外(すなわち新規利用者およびIP利用者)は、1時間以内に、{{Wtr}}または{{Wiktionary redirect}}を含むページおよび他ページへのリダイレクトページを3個より多く作成できないようにする。
理由 リダイレクトやソフトリダイレクトを乱造する系統の荒らしが活発であり、その対策。
対処操作 不許可

複数のLTAの対策上、あった方がいいフィルターである。--7ホゴク会話) 2021年7月24日 (土) 11:24 (UTC)[]

提案者は、2021年6月に同種のフィルターを提案した123.215.44.136と同一人物でしょうか。--ネイ会話) 2021年7月24日 (土) 11:45 (UTC)[]
いいえ、紛れもなく別人です。そのIPは使用したことはありません。また、ログインせずにWikipediaを編集したこともありません。--7ホゴク会話) 2021年7月24日 (土) 11:46 (UTC)[]
提案者はLTAとして無期限ブロックされました。--ネイ会話) 2021年7月24日 (土) 14:18 (UTC)[]
  コメント LTAによる不適切な提案ですし、巻き込まれへの対策も容易ではないフィルターですし即時終了で良いのではないでしょうか(既にコメントされたネイさん以外の編集フィルター編集者であれば対応可能と思われます)--郊外生活会話) 2021年7月24日 (土) 14:29 (UTC)[]

LTA対策編集

  提案中
目的 即時削除を乱用する荒らしを防止するため
理由 即時削除が乱用された結果、間違って削除されることの防止
発動条件 {{SD}}で置換
対処操作 不許可

--14.41.88.238 2021年7月23日 (金) 05:21 (UTC)[]

  •   反対 この条件で編集フィルターを作成したとき、荒らしではない利用者がタグを貼り付けた場合すら不許可になるおそれがあり、問題のあるフィルターと化することが予想できるため。--郊外生活会話) 2021年7月23日 (金) 08:17 (UTC)[]
  •   報告 提案者がWP:NOP違反かつLTA:SLIMEとしてブロック。無資格者による不適切な提案として即時終了でも構わないと思います。--郊外生活会話) 2021年7月24日 (土) 14:26 (UTC)[]

LTA対策(WP:VIP#アガリ対策)編集

  不作成
目的 3分か5分以内に{{Wtr}}か、{{Wiktionary redirect}}を含むページを7個以上作成した場合、以後20分は{{Wtr}}か、{{Wiktionary redirect}}を含むページを作成できないようにする
理由 アガリ系荒らしが活発で、不必要なページが大量に作成されているため
対処操作 不許可

特別:投稿記録/150.249.208.126のような不必要なページを大量に作成するのを抑制するため--123.215.44.136 2021年6月6日 (日) 03:38 (UTC)[]

  •   コメント 〇分以内に〜〜をX回以上したときに不許可、はできますが、「以降20分は・・・」はフィルターの仕様上難しいかと。であればIP・新規利用者にたいして、単純に〇分以内に特定テンプレートを含むページを数回作ったときに不許可、の方が現実的です。もちろん副作用についても検討する必要があるでしょう。--Q8j会話) 2021年6月6日 (日) 03:44 (UTC)[]
    •   返信 (Q8jさん宛) 以降も不許可にしないとまた作る可能性が出てきますが、その辺は仕様上無理なのでしょうか?--123.215.44.136 2021年6月6日 (日) 04:03 (UTC)[]
      •   返信 (123.215.44.136さん宛) うー、私はフィルター編集者でないですし仕様を完全に把握しているわけではないです(なので「無理です」ではなく、「難しいかとーと書きました)。無理、と断言はしません。多分、無理ですが・・・(現在Wikipedia‐ノート:編集フィルター#フィルターによるブロック機能についてが通れば、〇分以内に〜〜をX回以上したときに任意の期間ブロック、ができるようになります。が、本件に関しては誤作動が起こる可能性があり、あまり現実的ではないと思います)
      • ぶっちゃけ、フィルターで防げる荒らしなんてたかが知れてます。フィルターにできることは被害を軽減すること。もちろんフィルター12、他者利用者ページの編集禁止のように多分抜け穴が(規定の編集要件を満たす以外に)ないものもありますが、おそらくアガリはそのように「完全に防ぐ」ことは不可能です(ソフトリダイレクトの作成はそれ単体では方針に違反しないので)。
      • 当初の3分(5分)以内に7個作成、でも提示されたIP:150.249.208.126会話 / 投稿記録 / 記録 / Whois IPv4IPv6のようなものには効果的でしょう。無論、くどいようですが誤作動についても検討する必要があります(試験フィルター等)。--Q8j会話) 2021年6月6日 (日) 04:17 (UTC)[]
  • WP:NOPに基づき提案者を投稿ブロックしました。--ネイ会話) 2021年6月6日 (日) 06:37 (UTC)[]
    •   却下 1か月以上経過し、2人以上の賛成がなかったため、却下とします。--ネイ会話) 2021年7月24日 (土) 06:23 (UTC)[]

スパム目的でのYahoo!検索結果の追加荒らし対策編集

  提案中
目的 標準名前空間のページにおいて、スパム目的でのYahoo!検索結果を追加する荒らし対策
理由 LTA:GRIMM対策。LTA:GRIMMの個人ブログへ誘導するような主題と関係ないYahoo!検索結果のリンク追加を防ぐため。詳細は後述。

先ほども特別:差分/81181376のようにLTA:GRIMMの個人ブログへ誘導するような主題と関係のないYahoo!検索結果へのリンクが追加されていました。このような編集は以前からも標準名前空間の多くのページで行われているものであり、問題編集と考えます。そもそも、検索エンジンの検索結果へのリンクは、Wikipedia:外部リンク#掲載すべきでない外部リンクの7.の観点から外部リンクとして不適切であり、基本的には検索エンジンの検索結果へのリンクを載せるべきではありません。

MediaWiki‐ノート:Spam-blacklist/2020年#LTA:GRIMM案件 20190513で、MediaWiki:Spam-blacklistに載せるべきかという議論がありましたが、Spam-blacklistは名前空間での限定ができないため、削除依頼サブページでも使用できなくなる点で不都合であり、見送られています。編集フィルターであればその問題は解消できるかと思います。

おそらく「/search.yahoo.co.jp/search?」を含む文字列の追加を行ったときに引っかかる形にすれば差し支えないように考えます。対象ユーザーはLTA:GRIMM対策ですからIP利用者・新規利用者(自動承認されていない利用者)にすればかなり荒らしは防げるかと思いますが、拡張承認利用者だからといって標準名前空間でYahoo!検索結果へのリンクを追加することが妥当な場面は多分ないと思いますので(例外を挙げるなら、Yahoo!検索を直接主題とした記事あたりでしょうか。「3.11、検索は応援になる」などは発動対象外にするとして)管理者以外でも差し支えないようには思います(編集フィルターの運用上都合のよい条件で問題ないのではないかと思います)。もしLTA:GRIMMが半保護突破荒らしを行うようでしたら、LTA:GRIMMが突破できないような数値(これは荒らし対策上編集フィルター編集者以外が知らない方が良いと思います)のほうがよさそうには思います。

ただ、これはLTA:GRIMM以外のIP利用者・新規利用者が誤って追加して検出してしまう場合も考えられるかと思いますので、引っかかったときの画面でWikipedia:外部リンク#掲載すべきでない外部リンクの説明なども含めて別途案内文を作った方が良いのかもしれない、とは思っています。

まずは作成の是非に関してご意見をお願いいたします。--郊外生活会話) 2021年1月4日 (月) 12:48 (UTC)[]

GRIMMフィルターを運用した結果、フィルター避けとしてYahoo!検索へのリンクを使い出したようです。既存のフィルターに条件を追加する形で対応しても良いかもしれません。--Marine-Bluetalkcontribsmail 2021年1月4日 (月) 14:05 (UTC)[]
  返信 返信が遅くなりすみません。この類の編集を行う利用者がLTA:GRIMMだけであれば既存フィルターの条件変更でも良いと思いますが、「LTA:GRIMM以外のIP利用者・新規利用者が誤って追加して検出してしまう場合」が全くないとも思えず、その際にLTA疑いのようなメッセージを与えてしまうのはWP:BITEの観点から好ましくないのではないか、という懸念をもっています。--郊外生活会話) 2021年7月23日 (金) 08:22 (UTC)[]
  賛成 少し調べたのですが、LTA:GRIMMによるこの手の編集は遅くとも2019年から存在しているようです。3.11、検索は応援になるの除外を条件として作成に賛成します。標準名前空間内でのYahoo検索のリンクを禁止するというのも有効かと思いますが、それはまたの機会に。--Semi-Brace (会話 / 投稿) 2021年4月23日 (金) 01:54 (UTC)[]

連投対策編集

  提案中
目的 過度の連続投稿対策
理由 利用者:母語会話 / 投稿記録 / 記録のようなタイプの荒らしを防ぐため
発動条件 拡張承認された利用者、Bot以外による、1分間に6を超える投稿。action=editに限定されない。action=edit、move
対処操作 不許可

詳しくは利用者‐会話:Infinite0694の履歴‎Wikipedia‐ノート:井戸端の履歴をご確認ください。今回は今のところあまり大規模なことにはなっていませんが、発生すると対応されるまでの害が甚大なので対応が必要と考えます。action=editに限定されないとしたのは同じことは移動などでも可能だからです。--Q8j会話) 2020年11月2日 (月) 18:49 (UTC)[]

  •   コメント 何らかのツールを使っている人は別かもしれませんが、活動開始から3年以上、編集回数2万回を超えている利用者でも9編集/分が限界(Wikipedia:井戸端/subj/複数の記事に投稿するときの間隔について参照)なので、手作業で投稿する限りは不運にもフィルターに引っかかりそうな新規利用者さんはあまりいなさそうには感じます。ただ、いまの条件だと、巻き戻し権限保持者(巻き戻し者・管理者・グローバル巻き戻し者・グローバル管理者・スチュワード)が巻き戻し権限を適切に使用できなくなるリスクがあると思うのですが、どうなのでしょうか(これらの権限保持者が拡張承認された利用者であるとは限りません)。あと、場合によってはLTA:203LTA:SASHO対策、action=create も入るかと思いますのでLTA:YAYURE対策にもなるかと思います。--郊外生活会話) 2020年11月2日 (月) 19:07 (UTC)[]
    •   返信 あ・・・グローバルの存在をすっかり忘れていました。
    • mw:Extension:AbuseFilter/Rules_format/ja#組み込みの変数をみて気付いたんですが、編集フィルターってdelete=削除を検出するんですね。なのでactionをなんでもありにすると今後拡張承認されていない利用者が削除者になった際、一括削除(Nuke)の使用に支障をきたす可能性があるようです(削除操作によるフィルター発動記録)。迂闊でした。
    • なので、その対策も兼ねて、actionを限定した方がいいと思います。ところで、action=create、というのはページ作成のことでしょうか?であればaction=edit扱いなので、edit、moveで対応可能です。巻き戻しはおそらくどのactionにも属さないので(私は巻き戻し操作でサイズの大幅な増減などのフィルターに引っかかったことはないです)、この2つに限定すれば巻き戻し対策にもなると思います。--Q8j会話) 2020年11月2日 (月) 19:34 (UTC)[]
      •   コメント 確認してみましたが、巻き戻しはaction=editになります。なので、巻き戻しでの大幅増減は個別試験ではフィルター20などに引っ掛かりますが、理由は知りませんが編集フィルター記録には残らない様です(理由知っている方教えて下さい)。--えのきだたもつ会話) 2020年11月3日 (火) 04:56 (UTC)[]
        •   コメント 巻き戻し (rollback) は "action=edit" にはなるのですが、編集フィルターを通過しないため、編集フィルター記録を含めた全ての対処操作は実行されません (フィルターを通過しないのか、それとも巻き戻しは無条件でフィルターをパスできるのか、正確にはどちらなのかはわかりません)。そういう仕様です。phab:T24713 および phab:T262157 で意見が交わされています。--Yuukin0248[会話/投稿記録] 2020年11月3日 (火) 06:26 (UTC)[]
          •   コメント mw:extension:AbuseFilter/Rules_format#Exclusionsに解説がありました。「Although the AbuseFilter examine function will identify "rollback" actions as edits, the AbuseFilter will not evaluate rollback actions for matching.」。巻き戻しのリンクがaction=rollbackなのでてっきり別のアクション扱いされるのかと思ったんですが、そもそも検査されないみたいですね・・・MediaWikiのコードを編集している方にも確認しましたが、巻き戻しは編集フィルターによって処理されないようです。--Q8j会話) 2020年11月4日 (水) 04:16 (UTC)[]
      •   コメント action=createはページ作成のつもりで発言していたのですが新規作成もaction=editでした(保護記録で[edit=autoconfirmed]とか[create=autoconfirmed]とかあったり、特別:ログ/createがあったりするので別なのだろうと誤認していました)--郊外生活会話) 2020年11月3日 (火) 07:19 (UTC)[]
  •   コメント 一点思いついたのですが、その利用者が「noratelimit」権限を持っている場合は除外、というのはどうでしょうか。その場合削除者含む権限持ちはほとんど除外できるので、権限操作をこのフィルターが阻害することはないでしょう(削除だけならaction≠deleteで対応できますが、他の権限操作を阻害する可能性が否めません。今思いついたのが、管理者のmassprotect発動に伴う{{Pp}}(旧:{{半保護}}等)貼り付け。拡張承認されていない人が管理者なったらどうするの・・・?とか。)。もちろん、そうなるとそれら権限持ちは一利用者としての編集などでもこのフィルターを免れることになりますが、このフィルターの目的は単なる連続投稿防止ではなく、連続投稿による(Botのような)荒らし阻止なので、権限持ちはその観点からは省いていいように思います。なお、jawpローカル巻き戻し者はnoratelimitを持っていないので、jawp巻き戻し者であるというだけでは除外されません(拡張承認者であれば除外ですし、巻き戻し権限の行使は前述の通り除外ですが)
    • noratelimit権限保有者は以下の通りです。
      • jawpローカル・・・アカウント作成者、ボット、ビューロクラット、削除者、スチュワード(ローカルは0人です)、管理者
      • グローバル・・・Jimbo Wales's group、Global bots、Global rollbackers、Global sysops、New wikis importers、Staff、Stewards
    • この方法であればbotの除外も必要ない(botはnoratelimit持ち)ですし、actionを限定する必要もなくなります。1点問題があるとすれば拡張承認されていないインターフェース管理者が誕生した時ですが、まぁその時は手動で拡張承認つければ済みます(そんな滅多に起こらないであろう事態のために条件増やしてフィルター重くするのも良くないですし)。--Q8j会話) 2020年11月4日 (水) 23:22 (UTC)[]

  •   コメント 改めて(止まったので)
    • 発動条件・・・「拡張承認された利用者」でなく(user_groups)、noratelimit権限(user_rights)を持たない利用者が1分間に6を超える(7以上の)投稿をした時
    • 対処・・・不許可
で提案します。--Q8j会話) 2020年11月10日 (火) 08:15 (UTC)[]
  •   賛成 依頼者票--Q8j会話) 2020年11月10日 (火) 08:15 (UTC)[]
  •   コメントフィルタの必要牲には基本的に同意します。また、ご提案の仕様であれば重大な副作用の恐れもなさそうなので、この仕様なら安心して賛成できます。ただ、先の議論でいろいろとフィルタの仕様について聞いたのでわかったのですが、Q8jさん御提案の仕様ですと、発動条件を満して投稿不許可になっても、1分待てばまた最大6回の連続投稿が可能になってしまいます。対象としている荒らしはおそらくスクリプトなどを使って投稿していると思われるので「6回の連続投稿⇒1分待ち」のルーチンで簡単に対処されてしまいそうです。
そこで、仕様としては、発動条件を満した場合、投稿不許可ではなく、実質的な24時間程度の投稿ブロック、とすることを提案します。もちろんフィルタでは特定のアカウントに対するブロックはできません。そこで、最初に発動条件を満した時は、不許可にすると同時にフィルタが発動した、というフラグ(タグ)を付けておく。1分以上経過してから次の投稿があったときは、直前の投稿にフラグが付いていて、かつその投稿から24時間以内である場合に不許可とする、という方法で実質的に24時間の投稿ブロックができると思います。--Loasa会話) 2020年12月31日 (木) 08:12 (UTC)[]
(追記)フィルタでは基本的にブロックはできないと思っていたのですが、仕様書を見たらできるようですね。ならば、上で提案したようなややこしい方法ではなく、発動したら24時間かそれ以上のブロックということでよいでしょう。まともな利用者が引っかかることはまずありえない発動条件なので、通常のブロックと違って、利用者ページの編集も不許可でよいと思います。--Loasa会話) 2021年1月4日 (月) 05:05 (UTC)[]
  •   返信 ありがとうございます。
  • まず仕様の問題で、Wikipedia日本語版ではフィルターによる投稿ブロックはできません(確か)。サイトMediawikiで公開されている拡張機能・AbuseFilterは投稿ブロックを設定次第で行えるようになっていますが、日本語版ウィキペディアでは無効化されていたと思います。
    • 例えば、Special:AbuseFilter/1(カテゴリを含まない記事の作成・公開フィルター)の編集画面をご覧ください。編集はできませんが、画面下にスクロールすると「発動したときに取る対処操作」の選択肢(チェックボックス)に「ブロックする」というのがないのがおわかりいただけると思います。
  • その前に提示された「実質的な24時間程度の投稿ブロック」について、mw:Extension:AbuseFilter/Rules_format/jaにフィルターで使える変数が載っていますが、私の知る限り「当該利用者の直前の編集に〇〇というタグがついているか否か」という判定はできません・・・Loasaさんは何か方法をご存知でしょうか?
  • 『「6回の連続投稿⇒1分待ち」のルーチンで簡単に対処されてしまいそう』。はい、おっしゃる通りです。そうでなくとも10秒間隔でやり続ければこのフィルターには引っかかりません。
  • 連続投稿の害は大きく2つです。
    • 最近の更新監視に差し障る
      • 曜日、時間帯によって大きく違いますが、例えば今(1/4(月) 23:08JST)に見てみると500件表示で22:33:14JSTが最古、23:08:04JSTが最新です。つまりこの時間帯、34分50秒の間に500回の編集等が行われたことになり、1分につき15回ほど、監視すべき編集が流れています。
      • ここで先日のような、1分に30もの編集をされると、流れてくる量が3倍に跳ね上がります。もちろん利用者名などを見てスルーすれば良いのですが、場合によっては他の荒らしを見逃す結果になりかねません。
      • しかし、1分に6であれば、一時的に少し増える程度です。もちろんいいとは言いませんが、機械的フィルターで誤作動を少なく防ごうと思えばこれくらいが御の字と私は思います。
    • 履歴が汚れる
      • 先日はたまたま早く対処されましたが、例えば深夜、3時などにこれをされるとどうなるか。偶然管理者が起きてるか、スチュワードが事態に気付いて対応するまで、30/分ペースで履歴を埋められてしまい、例えば1時間放置されると1800版が流されてしまうことになります(デフォルトの50件表示だと36ページ分)。3時間対処されなければもう履歴分離ラインです。しかし、1分に6回ペースであれば、3時間放置されても1080版。最悪特定版削除で消すことができます。
  • 投稿ブロックについて、仕様上おそらく無理だと思う、と言いましたが、本件に関してはできたとしてもやるべきではない、と思います。不許可については(荒らしが)発生したときの害が大きいこと、スクリプトを使わない人はおそらく引っかからず、スクリプトを使うような人はある程度jawpに慣れていることが想定されること、メッセージで1分6回を超えたから不許可になった旨を出せば事情を理解するのは容易であることから(サーバー負荷の観点から、と言ったメッセージでもいいでしょう)提案しましたが、このリミットに引っかかる善良な利用者が皆無とは断言できないからです。
    • 一例として、Twinkleの存在が挙げられます。要するに巻き戻しスクリプトなのですが、この例のように1分間に6を超える事はあり得ます。そしてTwinkleは拡張承認されていない利用者が使うこともあるので、それでブロックして、さらに会話ページまで塞ぐのはちょっとまずいという印象です。
  • 長くなりましたが、以上です。--Q8j会話) 2021年1月4日 (月) 14:46 (UTC)[]
  •   コメント (まず技術的な話題から) Q8jさんの仰るとおり、不正利用フィルター拡張機能には「フィルターに引っかかった利用者を投稿ブロックする」対処操作がありますが、ウィキメディアプロジェクト全体で無効化[1]されています。ウィキペディア日本語版の独自設定[2]でも有効化されていないため、現時点で利用することはできません。この設定はメタウィキ[3]やウィキデータ[4]では有効化されており、合意形成を経てシステム管理者に設定の変更を依頼することは可能ですが、この設定の変更すると「編集フィルター編集者が間接的に投稿ブロック権限を行使できる」「誤作動によって非常に重い副作用が発生する」といった問題が起こるとして提案が否決される可能性もあります。ちなみに、直前の編集のタグから連続投稿を判断し実質的な投稿ブロックを行うという実装は、Q8jさんが説明されているような点で実現可能性が低いです。
  • (ここからが本題) 過度の連続投稿を抑制するためのフィルターを作成するという趣旨には賛成ですが、6回/分 を超えるスピードでの編集を行った拡張承認されていない利用者を24時間投稿ブロックするという提案には反対します (投稿ブロック対処自体に対する反対ではなく、その条件に対する反対です。後述)。善良な利用者が駅ナンバリング高速道路ナンバリングなどのテンプレートやカテゴリを追加するような簡単な編集であれば 6回/分 を超えて編集する可能性があります (もちろん継続的には無理、一時的にそういうタイミングがあるという話)。無論、6回/分 を超えていると言っても大きく超えているわけではないですし、善良な利用者であれば警告を見て内容を理解し速度を抑制するでしょう。むしろ、6回/分 を1度でも超えてしまっただけで24時間の投稿ブロックとなるというのは、善良な利用者にとっては厳しすぎる措置です (というか、最大 12回/分 で短時間だけ走る仮運用Botまでも投稿ブロックされます)。問題となっているのは荒らし目的の連続投稿で、これらは「より速い速度・より長い時間」連続投稿を行います。
  • (結局の所…) 荒らし目的の過度の連投を正確に判断して投稿ブロックしながら、善良な利用者に対する影響を限りなく低減することは不可能だと思います。その2点を両立させるためには、6回/分 を超えたら不許可で、投稿ブロックは行わない、という当初の提案は理に適っています。6回/分 では荒らし対応が遅れた際の被害が大きいという意見があるので、4回/分 や 3回/分 まで厳しくするのもありだと思います。どうしても投稿ブロックするならば、善良な利用者が普通に編集してて99%出せない速度 (8回/分 だとギリギリ出せるかも?10回/分 は無理だと思う) のみに絞るべきです。あるいは、同一ページに対する 4回/分 や 6回/分 の連続投稿に絞って投稿ブロックを行うのも有効かもしれません。--Yuukin0248[会話/投稿記録] 2021年1月5日 (火) 08:05 (UTC)[]
    •   コメント Yuukin0248さん、技術的情報の補足、ありがとうございます。ウィキメディアプロジェクト全体の設定だったんですね・・・
    • さて、ブロック/実質的なブロックという案は技術的に不可能なようです。これは見送りとさせてください。
    • 今朝(深夜)、LTA:SYUNである利用者:勤怠卿会話 / 投稿記録 / 記録が懸念していたような編集を行いました。幸いスチュワードがすぐにロックしてくださったので大事には至りませんでしたが・・・特定のLTAに限らず、こういうのはJavaScriptやbotの知識があれば誰でも可能なものです(Special:Diff/78148270によると、自動承認だけで前述のような速度の編集は可能)。できれば可能な限り早く対策を行いたいです。
      • Loasaさん、Yuukin0248さんは前向きな意思を示していただいていますが、Wikipedia:編集フィルター/提案#提案から正式稼動までの流れにある「賛成」とみなして差し支えないでしょうか。もちろん条件で他に検討することがあれば議論すべきですが、Loasaさんに上記のコメントをいただくまで2ヶ月停滞してしまっており、またいつの間に流れる、というような事態は避けたいところです。
    • 仮運用などフラグなしbotがこのフィルターに引っ掛かった際はWikipedia:管理者伝言板/拡張承認の申請#拡張承認の申請にあるとおり拡張承認された利用者権限をつけることで対応することになるかと思います(ただ方針上OKとはいえ、フラグなしでそんな早くbotを動かす人もいないと思うのですが、ログ取得期間中に引っ掛かったフラグなしbotの数によっては何か対策が必要かもしれません)。--Q8j会話) 2021年1月7日 (木) 12:49 (UTC)[]
  •   賛成 ブロックも実質的なブロックも技術的に不可ということなら、別にブロックすることに拘っているわけでもないので、Q8jさんご提案の仕様に同意いたします。なお、運用上は、効果を見ながら、発動条件を1分あたり6回から1分あたり3-4回などと変更してみるのも良いかもしれません。ただし、数値を固定で運用するのならこのままで良いのですが、もし数値を変えるならば絶対に守っていただきたい条件があります。それは、頻度計測の分母の数値、すなわち1分という時間は変えないでいただきたいということです。あるいは、1分では短か過ぎるのでもう少し長い時間で計測したい、ということであれば、計測時間の最大値を定めてその値は公開し、その最大値以下の時間で変動させていただきたい、ということです。その理由については、すでに半保護突破のための編集数稼ぎ防止さんざん述べた通りです。似たような目的・仕様のフィルタであるにもかかわらず、「半保護突破のための編集数稼ぎ防止」の場合と違って、こちらの提案にはあっさり賛成し、それどころか「24時間ブロックしても良いのでは」などと過激なことさえ述べたのも、こちらのフィルタは数値が最初から公開されている上に、ご提案の1分あたり6回という発動条件であればまともな利用者が引っ掛る可能牲はまずほとんどない、と考えられるためです。--Loasa会話) 2021年1月10日 (日) 15:44 (UTC)[]
  •   コメント Loasaさん、ありがとうございます。二人の賛成票がついたので、合意とみなせると思います。
  • 個人的に、数値は固定でいいと思います。理由は上で述べた通り、1分間に6以下であればそこまで緊急な問題にはなりづらいからです。「1分あたり6回から1分あたり3-4回などと変更してみるのも良いかもしれません」というご意見について、もちろんできるならそれがベストですが、巻き添えを少なくしようと思えば6くらいが限度なのだろうなぁと予想しています。
  • よろしければフィルター編集者さん、対応(試験フィルター)していただけると助かります。
  • ちなみに条件は上で言った通り『「拡張承認された利用者」でなく(user_groups)、noratelimit権限(user_rights)を持たない利用者が』ですが、『「制限されたページを編集」(extendedconfirmed) ,「速度制限を受けない」(noratelimit)権限を持たない』でもいいかもしれません(速度的にどっちがいいんだろう?)。そのように変更した場合、新たにローカルインターフェイス管理者、Global interface editorsが影響を受けなくなりますが、彼らが連投荒らしをすることはないでしょうし。--Q8j会話) 2021年1月15日 (金) 10:15 (UTC)[]
  •   賛成 高速での投稿を不許可することによって大きな問題になることはほぼないと考えられるため、Q8jさんご提案の仕様でいいと思います。条件式はどっちでも良いと思います。仮運用Botについては、速度コントロールができているかを確認する目的で方針上200回までは高速運転可能となっているため、引っかかってしまうと仮運用できなくなります。--Yuukin0248[会話/投稿記録] 2021年1月23日 (土) 07:58 (UTC)[]

YouTubeのチャンネルを直接貼った編集のトラック編集

  提案中
目的 {{SD|G4}} が付けられるような記事の作成防止
理由 P丸様。ノート / 履歴 / ログ / リンク元 チャンネルがーどまんノート / 履歴 / ログ / リンク元など、明らかに宣伝が主目的のページを作成される確率を減らす
発動条件 新規作成されたページ、標準名前空間、バイト数が1000未満、任意の行に https://www.youtube.com/channel を含むという条件を全て満たす編集
対処操作 警告

最近作成されるYouTube(r) 関連の記事で、特筆性のないページのほうが多くなってきたと思われるため上記の通り提案します。--Semi-Brace (会話 / 投稿) 2020年10月31日 (土) 06:39 (UTC)[]

  •   コメント 不許可ではないとはいえ、逆に警告のせいでYouTuberのリンクを除去されるほうが困るときもあるように考えています。記事主題が実在するかどうかの確認で有用に考えますし、一般にYouTubeのリンクはWP:ELの観点から問題ありません。バイト数が1000を超えていたからといって宣伝的な記事はあるでしょうし(サブスタブ作成対策を意図しているなら別ですが)、個人的にはrefタグの有無あたりも判断根拠に入れても良いようにも思えます。--郊外生活会話) 2021年1月4日 (月) 13:01 (UTC)[]

初版からある修正テンプレートの追跡編集

  不作成
目的 Category:修正テンプレートが貼られたまま作成されるページの検出
理由 そもそも修正テンプレートは初版から貼って他人に修正を告知する趣旨で作られていないため。
発動条件 新規作成、かつ作成時のテキストにCategory:修正テンプレートのいずれかの呼び出しが含まれている場合
対処操作 タグ付け

Category:修正テンプレートだと広すぎる気がするのでご意見を募集したいと思います。--Semi-Brace (会話 / 投稿) 2020年10月23日 (金) 06:08 (UTC)[]

俺の嫁コピペ対策編集

  提案中
目的 LTA:SASHO対策
理由 最近この履歴などに出現している俺の嫁からのコピペを行う利用者が散見されるため
発動条件 プラス1000バイト以上、編集回数が50回未満、同記事からのコピペを行った時
コード action = "edit" & edit_delta >= 1000 & user_editcount < 50 & page_title != "俺の嫁" & "俺の嫁(おれのよめ)とは、" in added_lines & "『知ってるだけで恥ずかしい 現代オタク用語の基礎知識』" in added_lines
対処操作 不許可

繰り返される荒らしに対する即時版指定削除+リバートを減らすのが目的です。5つめ、6つめの条件は暫定です。--Semi-Brace (会話 / 投稿) 2020年9月21日 (月) 05:24 (UTC)[]

  •   賛成 どのくらいの頻度で出てるのか私はよく知らないんですが、そう言う方がいるなら作成に同意(沈静化したらその時は解除すればいいでしょう)。特定のワードを公表しちゃうと回避がされる可能性があるので、例えばいくつかの普通では考えにくいワード・文を設定して、何個以上含まれたら不許可とか言うのもありだと思います。--Q8j会話) 2020年9月22日 (火) 20:32 (UTC)typo--Q8j会話) 2020年9月22日 (火) 20:33 (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)[]
  •   コメント 特別:不正利用フィルター/14Unicodeの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)[]

  賛成 別案は最初の案と比べて穴がある代わりに、コードがかなりシンプルになっています。追跡カテゴリがあるので、コードのシンプルさを重視して別案に賛成します。最初の案にも反対はしません。--ネイ会話) 2021年4月4日 (日) 12:26 (UTC)[]

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

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

下記2つ提案します。

フィルターA編集

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

フィルターB編集

  提案中
目的 省略(下記記載)
理由 省略(下記記載)
発動条件 投稿回数100回未満の利用者が、
  • リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時
  • ページ作成から5分以内のページを移動しようとした時
コード user_editcount < 100 & ( ( action=='edit' & page_age < 600 & old_size < 309 & contains_any ( old_wikitext , '#転送' ) ) | ( action == 'move' & moved_from_age < 300 ) )
対処操作 不許可
この提案は複数回変更されています。履歴を表示するには「表示」を押してください
この提案フィルターの前身
  1. 2020/02/01 Wikipedia名前空間での移動を防止するフィルター提案→取り下げ(→フィルターA)
  2. 2020/03/06 他者会話ページの移動を防止するフィルター提案→取り下げ(→フィルターA)
  3. 2020/03/16 リダイレクトページの編集を防ぐフィルター提案→取り下げ(→フィルターB)
このフィルターの履歴
1.2020/05/28 初提案。
  • 投稿回数100回未満の利用者が、1時間以内に3回以上ページ移動を行った時(フィルターA)
  • 投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集・移動しようとした時(フィルターB)
2.2020/08/06 条件変更、コード草案作成
  • フィルターAの発動条件の回数を1時間に3回から5回に変更
  • フィルターBの「移動」についてリダイレクトページのみ、の判定ができないことが分かったため、ページ作成後10分から5分に短縮した上で、作成後5分以内のページ移動はリダイレクトかそうでないかを問わず発動するように変更
3.2020/08/08 コード微修正
  • 反応速度の向上のためにcontains_any ( old_wikitext , '#転送' )の発動前にページのバイト数を確認、308バイト以下の時はcontains_any ( old_wikitext , '#転送' )の検査を避ける(old_wikitextは重い場合があるそうなので)

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

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

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

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

  賛成 普通の利用者なら10分ぐらい待てますが、荒らしであれば早急に荒らさないとブロックされるので、そういった意味で有用な編集フィルターであると思います。1つ目の編集フィルターで、投稿回数100回未満の利用者が行った移動にタグ付けをするとかそういうのがあってもいいと思いますが、まあそれについてはどちらでもいいと思いますし、初心者の方が「なんだこれ??」となるかもしれないのでタグ付けはなくてもあってもどちらでもいいです。--Tmv会話|投稿記録) 2020年6月19日 (金) 00:46 (UTC)[]
  •   コメント 「もし、提案後1週間が経過し、2人以上の賛成(提案者の提案者票を含めても良い)があり、かつ反対する人がいない場合は、合意がなされたとみなされます。」の要件を満たし、本件フィルターは合意がなされています。本日、LTA:203と思われる移動荒らしが2体出現したこともあり、可能ならフィルター作成をおねがいしたいです。--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回までしか移動できなくなってしまいます。なので2倍にしたいところですが、逆に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)[]
  •   コメント 通知が来たので回答いたします. 回数の変更についてですが, 4回まで移動というのは妥当であると思います. 荒らしがノートのないページを移動で荒らすときと, 一般利用者がノートのあるページを荒らすときの間を取るのって結構難しいですね. 一般利用者さんが移動するときは合意形成を取ってから移動しますからノートがある場合も多いと思いますし, 荒らしの場合はノートがないページの移動も結構あると思います. そういうのを鑑みると4回というのは妥当な数字だと思います.
  • 2つ目についてですが, こちらについても賛成です. ページ作成から5分以内のページを移動しようとする, という操作についてですが, 一応明らかなページ名のミスなどがわかってすぐ移動する例というのはあります. ただ, 5分以内なので待てばいいですし, 投稿回数100回未満の利用者がミスを見つけて移動するという操作をすることも少ないと思います.
  • 以上です. 私は変更後の案に賛成いたします. --Tmv会話|投稿記録) 2020年8月6日 (木) 23:01 (UTC)[]
  •   報告 何度もすみません、微修正しました。今回は発動条件は(理論上)変わらず、パフォーマンス向上のみです(・・・多分)。ので、追加期間はとりません(意見があれば別です)
    • 変更箇所。「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」の部分のコードに太字部分を加えました。user_editcount < 100 & action=='edit' & page_age < 600 & old_size < 309 & contains_any ( old_wikitext , '#転送')
    • 私の理解が正しければ、フィルターは左から右に検査して、途中で引っかかればそれ以上の検査はしないはずです。つまり、この変更により編集前のサイズが309バイト未満であればcontains_any ( old_wikitext , '#転送')=ページに「#転送」が含まれるか、の検査が行われますが、309以上であればこの検査は行われません。
    • 理由ですが、old_wikitextには「この変数は膨大な場合があります。」との解説があります。ので、可能な限りその検査をしない条件を考えました。このフィルターが狙っている「自動生成されたリダイレクトの改変防止」という目的であれば、この検出対象は#転送 [[(名前空間:)ページ名]]の形のはずです。そのうち、#転送 [[名前空間:]]の部分は最大で「プロジェクト‐ノート:」名前空間の#転送 [[プロジェクト‐ノート:]]、43バイト。名前空間を除いた部分の最大は255バイト。なので、移動により生成されるリダイレクトページの最大サイズは298バイト。それに余裕を持って+10した308より大きいバイト数は理論上移動により生成されたリダイレクトページじゃ無いので、弾く必要はなく、old_wikitextの検査をする必要がないと判断しました。--Q8j会話) 2020年8月8日 (土) 11:57 (UTC)[]

  •   取り下げ 作成/却下の判断や他のコメントがなされないまま3ヶ月経過してしまったので取り下げます。--Q8j会話) 2020年11月27日 (金) 17:08 (UTC)[]
  •   コメント すみません。取り下げを取り消します。最近もたまに見かけるようになったので。もちろんフィルター編集者さんが却下されるなら仕方ないですが、依頼者の私としては(試験)フィルターの作成を引き続き希望します。--Q8j会話) 2021年4月18日 (日) 10:18 (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)[]
      •   却下 1年以上経過し、2人以上の賛成がなかったため、却下とします。--ネイ会話) 2021年7月24日 (土) 06:22 (UTC)[]

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

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

LTA:ASPELTA:203LTA: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日間承認されない仕様」ということは、その5日間はどんなに多くの編集をしても「自動承認された利用者」にならない、ということでしょうか。
  返信 その認識で合っています。
A-2. また、5日間経過したら即座に「自動承認された利用者」に戻れるのでしょうか。それとも取消しの瞬間にリセットされ、5日間経過した後さらにまた4日経過し10回以上の編集がないと「自動承認された利用者」に戻れないのでしょうか。
  返信 試していないので、確かな答えは現時点では提供できませんが、おそらく「5日後に即座に自動承認される」と思います。(1回編集する必要のある拡張承認とは仕様が違います)
A-3. また、「5日間」という期間は仕様上固定されたものでしょうか。設定でこの期間を変更することはできないのでしょうか。
  返信 現時点では正確には「432,000秒」(=120時間=5日)に固定されており、変更はできません。
A-4. また、「自動承認された利用者」になる以前の段階で取消しになった場合はどうなるのでしょうか。やはり5日間は何をしても「自動承認された利用者」にならないのでしょうか。
  返信 その認識で合っています。
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. 取り消されてから5日の間に再びフィルターの発動条件に引っ掛った場合、自動承認されない期間はその分延長されるのでしょうか。たとえば、最初に取り消されてから4日目に再びフィルターに発動された場合、最初に取り消されてから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)[]
@Loasaさん、Q8jさん、Taisyoさん、片割れ靴下さん: 5月以降、議論が停止しています。今のところ、Loasaさんの仕様案をベースに議論を再開できそうだと思いますが、どうしましょうか?--ネイ会話) 2020年8月24日 (月) 09:42 (UTC)[]
  • うーん。僕自身の最近の感想として、最近はLTA:203が目につくんですが(移動荒らしという比較的めんどくさいことをされるためでもある)、結局のところ「バイト数を満たせば投稿はできる」わけですよね。多分発動して、見たら編集フィルターという機能によって阻止されたことがわかる。そしてフィルターのページからこのページにたどり着くことができれば、バイト数が規定より少ない、という条件はわかる。そうなれば適当にバイト数稼げばいい、ということはさすがにわかるでしょう。バイト数を稼ぐために、下手したら著作権侵害のおまけがついてくるかもしれません。・・・というのは203が「阻止されたのが編集フィルターという機能によること」「それが提案(裁量ではない)されたものとわかる(≒このページのフィルターからこの節を見つける)」「それを回避する方法がわかる」という、希望的観測の逆・・・絶望的観測によるわけですが。つまり条件が悟られたらその時点で実質(そのLTA相手には)無駄なフィルターになる可能性はあると思います(もちろんバイト数を増やすことで多少は対応できるでしょうが、こっちが2倍にするだけで巻き添えを考慮しないといけないのに対し、あちらはコピペ一回で済むわけで、いたちごっこはこっちが圧倒的に不利です)。というわけで効果は疑問(正確にはいつまで保つか疑問)ですが、まぁ効かなくなったら残念でした、で無効化すればいいですし、一時的でも効けばその一時は効果がある。希望的観測ですが、悟られなければずっとLTAの邪魔ができるかもしれない。というわけで、色々書きましたが概ね賛成です。
  • 仕様について、Loasaさんの案に少し考えてみました。
    • F2。500回、とおっしゃいますが、このフィルターの目的は半保護突破防止のはずです。自動承認されていないが、IPでもない、で十分では?(投稿回数が10回を超えたら、その後の編集は「半保護突破目的」ではなくなりますし、拡張半保護突破は到底現実的ではない)。必要ない利用者の編集を検出することは負荷、誤作動につながります。
    • F3、対象ページ。私はすべてのページではなく、「標準名前空間以外」でいいような気がするんですが、どうでしょうか。現時点203がターゲットに使うのはサンドボックスが圧倒的に多いという印象ですが、LTA:ASPELTA:Iccicは標準名前空間を使うのでしょうか?(LTAページを見た感じでは使わなさそうな感じですが)使わないのであれば、単純に「標準名前空間以外」を条件として、標準名前空間を踏み台にされるようになったら、その条件を撤去することを検討されてはいかがでしょう。標準名前空間を除外するというふうに条件を厳しくすれば、その分要件(Loasaさんの「T」「B」「N」)を緩く(検出しやすく)できるかもしれません(あくまで慎重に)
F2、F3共にあまり拘りません。--Q8j会話) 2020年8月25日 (火) 08:03 (UTC)[]
Loasaさんの仕様案を元に「閾値を非公開にする」のであれば、良いのではと思います。Q8jさんの指摘の通りです。閾値がバレた時点で、それを狙って編集するだけなのではと思います。やはり、ある程度は心理戦の部分があり、極端に厳しくすると誤爆が増えるリスクが大きいです。そうしないためには、柔軟に閾値を変えた上で、非公表にするが一番実効性が高いと思います。
対象LTAについても、指摘の通りLTA:ASPEについては、特に荒らす記事を拡張半保護。LTA:Iccicは薄々は気が付いているのだけど・・・状態でLTA:203対策に限定で良い様に思います。提案時と半保護の仕様が変わったのは大きいです。--Taisyo会話) 2020年9月11日 (金) 10:49 (UTC)[]
  • コメントが遅くなってすみません。私の意見は特別:差分/77290891の後半で述べたことがすべてですが、もう少し演説します。フィルタに限らずこの種の防御システムは、その効用や緊急性・重大性と副作用のバランスで考えるべきです。たとえば、その防御システムが対象とする問題行為が、ウィキペディアに対して致命的といえるほど重大な損害を与えるようなものであり(重大性)、かつ、緊急な対策を要するものでもあり(緊急性)、かつ、その防御システムがその行為に対する阻止として有効に働く(効用)ものであるならば、若干の副作用はやむを得ないでしょう。しかし本フィルタの対象とする問題行為は、そこまでしなければならないほど緊急性や重大性の高いものではありません。有効性という点でも(パラメーターを非公開にしたとしても)上でコメントされているようにいずれは突破されてしまうだろうし、多少時間をかければフィルターの意味もなさなくなる可能性が高いものです。本フィルタの効果はその程度しか期待できないのに対して、無関係な初心者が引っかかる確率がほぼ100%であり、しかも短時間とはいえ、ブロックの可能性もあるというリスクは効果に見合ったものとはいえません。そして、フィルタの仕様上、非常に高い確率で無関係な初心者が引っかかる可能性は避けられません。ならばせめて副作用が発生したときの救済措置を十二分に用意しておく必要があります。私の考えではその救済措置の一つがパラメーターの閾値公開なのです。初心者が引っかかったときにT時間待てば自動的に回復できる、とわかるだけでも安心できます。たとえ短時間でもそれがわからないのは非常な不安になるものです。
そのようなわけで、細かい仕様はお任せしてもよいのですが、パラメーターの閾値公開だけは絶対的な条件とします。ただ、多少は妥協して、NやBに関しては非公開でもよいでしょう。公開するのは最大ブロック可能時間、すなわちTの最大値だけでもよいとします。Tの最大値の公開すら駄目ということであれば、このフィルタは有用性のわりに副作用の害が大きすぎるということで、フィルタの作成自体に反対とさせていただきます。パラメーターTの最大値の公開すら認められない、ということであれば、それならばこのフィルタを作るのは止めましょう、というのが私の最終的な結論です。--Loasa会話) 2020年12月31日 (木) 07:18 (UTC)[]
  •   提案 前回の私のコメントから半年以上経過しましたが、Taisyo さんからの再コメントもなく、パラメーターの閾値公開については妥協・譲歩される余地はないようです。私としても前回のコメントで述べたとおり、これ以上の譲歩をする気はありません。したがって、本提案については合意が成立できなかったものと見做し、そろそろ合意不成立でクローズしてもよいのではないでしょうか。--Loasa会話) 2021年7月23日 (金) 22:39 (UTC)[]
実効性が落ちることを承知の上で、Loasaさんの仕様丸のみで導入はどうでしょうか。丸のみの上で不具合があれば見直しで。見直しの時は再度提案を入れる形になります。--Taisyo会話) 2021年7月24日 (土) 05:31 (UTC)[]
  • 丸のみということは「Tの最大値は公開する」という条件も含めた仕様で作成する、という理解でよろしいでしょうか。--Loasa会話) 2021年7月24日 (土) 06:48 (UTC)[]
「Tの最大値は公開する」で大丈夫です。此処で割れている訳ですので、とりあえず公表型で作りましょうです。公表された値に対して荒らしが対応しきれなければそのままですし、荒らし利用者が合わせてくるようであれば、再議論です。実働していないのに、結果を予想するのはある意味ナンセンスな気もしています。--Taisyo会話) 2021年7月24日 (土) 07:15 (UTC)[]
  • 了解いたしました。そういうことであれば作成に同意いたします。--Loasa会話) 2021年7月25日 (日) 02:46 (UTC)[]
  • で、Tの最大値として公表する値は12時間くらいが適当ではないでしょうか。実装上は、誤爆を避けるために Tを大きくすればNの値も大きくせざるを得ないし、実質的にはTが1時間程度であってもNの値はフィルターの意味がなくなる程大きなものになってしまうと考えられるので、12時間という制限は、実質的に実装上での制約にならないくらい十分すぎるほど緩い条件だと思います。--Loasa会話) 2021年7月25日 (日) 02:46 (UTC)[]
12時間。それだけあれば、たまたま引っかかった利用者が待つのには丁度良く。荒らし目的であれば、その間にブロックしたり、荒らし回数を減らしたり出来ますね。スタートの値として丁度良いかもしれませんね。--Taisyo会話) 2021年7月25日 (日) 13:11 (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)[]


試験中のフィルター編集

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

仕様変更提案編集

「追加除去キーワード一致」系の編集フィルターはキーワードが追加除去されていない場合に発動しないように正しく設定する編集

誤作動報告を眺めて気づいたのですが、特定のキーワードが追加除去された場合に発動するフィルターが悪質なコードになって偽陽性を頻発している事に気づきましたので、正しく修正を提案するものです。 修正が仕様の変更にも及ぶ可能性があるのでここに書きます。

具体的には、Aというキーワードに反応したいフィルターがあった場合

追加系
contains_any(added_lines, A)
除去系
contains_any(removed_lines, A)

というような式だけになっているフィルターが散見されます。 しかし上記のような設定の場合、最初から「Xである。Aである。」と書かれた行からXを除去して「Aである。」だけにしたり、あるいはYであると追加して「Xである。Yである。Aである。」とした場合にも発動して、編集自体にはキーワードが含まれていないにもかかわらず発動する誤作動(偽陽性=発動すべきではないのに発動してしまうこと)を引き起こします。 なぜなら(added|removed)_lines変数は名前にlinesと書かれている通り行単位だからです。 ですので、特に(ウィキテキスト上で)1行が長いページでは確率的に頻発します。 added|removedが分かりづらければ、それぞれ「編集後の行」と「編集前の行」と読み替えれば誤解することもないでしょう。

本来の意図は編集でそのキーワードが追加除去されたかを見たいはずなので、正しくは以下のようにすべきです。

追加系
contains_any(added_lines, A) & !contains_any(removed_lines, A)
除去系
contains_any(removed_lines, A) & !contains_any(added_lines, A)

つまりキーワードが「追加|除去された行に含まれている」だけではなく「追加|除去される前の行=除去|追加された行に含まれていない」こと確実に見る条件でなければいけません。

なお、念のため書いておきますが、上記コードはあくまで例であり、in,like系のキーワードや他の機能を使って同様の「キーワード検出」を意図したコードも対象に含まれます。

なぜこんなコードが多く存在してしまっているかというと、おそらく

  1. 最初に「追加除去キーワード一致」系のフィルターを作った編集者が、編集フィルターの仕様について無知であったためバグを埋め込み
  2. さらに動作状況について定期的な確認を怠って偽陽性に気づかないまま放置し動作し続けており
  3. それをまた別に無知なフィルター編集者が中身を理解せずコピペして(&発動結果の確認が不足して気づかず放置して)
  4. かついずれもフィルターの作成報告義務を果たさなかったためフィルターの内容周知が不十分で
  5. 上記2-3が繰り返されねずみ算的にバグコードが増加し
  6. 最後に止めるべき他のフィルター編集者の相互監視も不足し今日まで誰も指摘しなかった

という悪い連鎖があったのだと思います。 直接的には1-5番のような行動をしたフィルター作成者の責任が重いものの、最後の要因を考えれば、このような低質なフィルターが蔓延してしまったのを許したのは、私を含めたフィルター編集者全員の問題だったと思います。 特に、対処操作を不許可にしているフィルターにおいて偽陽性を埋め込んだ&長期間放置した&見過ごしたのは、なによりも避けるべきことであって(cf. ガイドライン)、これによって少なくない数の善意の利用者の意欲を削ぐことでウィキペディア日本語版の発展を大きく阻害してしまったことを自覚しましょう。

そこで、ここでは現時点で編集フィルターの編集権限を持っている全員に上記内容を通知し、以降に同様の問題を再発させないよう徹底させると共に、現時点で存在する(有効化されている)フィルターの全再点検&修正を始めたいと思います。

まず以下、フィルター編集者全員への通知&確認です(順は就任日順)。上記内容を全て読んで理解した方は、後ろに自分の4チルダ署名を書いてください。気になる点・不明点・コメントなどあれば本節末尾で解決してから署名をお願いします。 3ヶ月程度経過しても署名されていない場合は、フィルター編集者として活動する予定がないか、理解できる=フィルターを正しく設定するだけの能力が不足していると考えられるので、フィルター編集権限の除去依頼を出すことを先に予告しておきます。 また、追加作業や手戻りを避ける観点から、上記内容を理解するまで(署名するまで)、各位にはフィルターの新規作成を含むフィルターの編集は控えていただくようお願いします。

次に現時点で存在しているフィルターの確認&修正ですが、数がかなりあるので人海戦術するしかなく、上記で理解した署名をつけられたフィルター編集権限を持っている全員で、時間のある限り少しづつ協力をして、進めましょう。 以下の表に、少なくとも(added|removed)_linesが含まれる現在有効なフィルターの一覧を書いておきました(検索機能で抽出した)ので、これを全部埋めれば完了で良いと思います。

フィルター番号 対処操作(修正前) 修正の要・不要を確認した人 修正した人
編集フィルター#1変更履歴一致記録 タグ付け 不要 ----青子守歌会話/履歴 2020年12月26日 (土) 02:53 (UTC)[]
編集フィルター#5変更履歴一致記録 不許可 ページの作成時のみ発動するので修正不要。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC)[]
編集フィルター#10変更履歴一致記録 タグ付け ページの作成時のみ発動するので修正不要。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC)[]
編集フィルター#11変更履歴一致記録 不許可 ページの作成時のみ発動するので修正不要。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC)[]
編集フィルター#13変更履歴一致記録 警告、タグ付け ページの作成時のみ発動するので修正不要。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC)[]
編集フィルター#14変更履歴一致記録 不許可 ページの作成時のみ発動するので修正不要。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC)[]
編集フィルター#15変更履歴一致記録 タグ付け
編集フィルター#17変更履歴一致記録 不許可 要(上記指定の範囲外) 例えばこの編集はURLを含む出典を付けようとしたもので、有用な編集のように思われるが、そのURLがNGワード指定されているため失敗している。----Freetrashbox会話) 2020年12月28日 (月) 21:50 (UTC)[] フィルター#17の第2423版差分) --青子守歌会話/履歴 2020年12月30日 (水) 03:21 (UTC)[]
編集フィルター#18変更履歴一致記録 ※2015-07-19 誤作動多発で運用停止(それ以前は不許可)
編集フィルター#22変更履歴一致記録 警告 要修正。時系列に関するマジックワードの追加を検出し、警告を出すフィルターであるが、added_linesだけをチェックしていてremoved_linesは無視している。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC) 追記。--本日晴天会話) 2020年12月27日 (日) 04:29 (UTC)
この編集は提案者が指摘する誤動作の典型例のように思われる。ただしマジックワードにのみ反応するフィルターであり、動作が警告に留まることから、実害は比較的低いように思われる。--Freetrashbox会話) 2020年12月28日 (月) 21:50 (UTC)[]
編集フィルター#30変更履歴一致記録 タグ付け 修正不要。コメントアウトを検出し、タグ付けするフィルターであるが、added_linesとremoved_linesの両方をチェックしている。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC) 追記。--本日晴天会話) 2020年12月27日 (日) 04:29 (UTC)[]
編集フィルター#32変更履歴一致記録 不許可 コメント この編集はIPユーザーによる会話ページへの警告文が失敗した例で、有用と思われるが、警告文にNGワードを含むため仕方ないと言える。--Freetrashbox会話) 2020年12月28日 (月) 21:50 (UTC)[]
編集フィルター#33変更履歴一致記録 不許可 この編集は提案者が説明する誤動作の典型例のように思われる。----Freetrashbox会話) 2020年12月28日 (月) 21:50 (UTC)[] フィルター#33の第2462版差分
Wikipedia:編集フィルター/誤作動/報告#118.13.34.228:天皇制廃止論の対処として修正しました。--えのきだたもつ会話) 2021年1月17日 (日) 04:53 (UTC)[]
編集フィルター#35変更履歴一致記録
編集フィルター#37変更履歴一致記録 不許可 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#38変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#39変更履歴一致記録 不許可 要 一つのフィルターに複数のLTA対策を直列に入れたもので、大変に読みづらく、作成者以外には管理が難しいように思われる。例えばこの編集は、数字を変えているだけなので提案者の言う誤動作の典型のように思われ、おそらく元の文の何らかの事件名が作用したものと思われるが、拒絶された理由を簡単には特定できず、作成に当初から携わっていなかった人には修正が困難なように思われる。できればフィルター編集者同士の相互監視の観点から、もう少し全体を読みやすく調整するのが望ましいと思われる。----Freetrashbox会話) 2020年12月28日 (月) 23:24 (UTC)[]
編集フィルター#42変更履歴一致記録
編集フィルター#44変更履歴一致記録 不許可 修正不要?荒らしワードのチェックはadded_linesのみに行っている。対処操作が「不許可」なので、荒らしワードがremoved_linesに含まれている状況はおそらくあり得ない。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC) 訂正、追記。--本日晴天会話) 2020年12月27日 (日) 04:29 (UTC)[]
編集フィルター#45変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#47変更履歴一致記録 タグ付け 修正不要。Refタグつき記述の除去を検出し、タグ付けするフィルターであるが、added_linesとremoved_linesの両方をチェックしている。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC) 追記。--本日晴天会話) 2020年12月27日 (日) 04:29 (UTC)[]
編集フィルター#48変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#50変更履歴一致記録
編集フィルター#52変更履歴一致記録 不許可 不要 提案者が問題とする構文になっているが、過去の動作を見る限りでは、問題なく動作しているように思われる。----Freetrashbox会話) 2020年12月29日 (火) 01:11 (UTC)[]
編集フィルター#53変更履歴一致記録 不許可 この編集は起票者の指摘する問題が発生しているように思われる。また、同じ投稿者によりトラップが簡単に回避されていることから(投稿内容には問題なさそうだが)、LTA対策としても微妙なように思われる。----Freetrashbox会話) 2020年12月29日 (火) 01:11 (UTC)(訂正) この編集は起票者の指摘する問題が発生しているように思われるが、投稿者が改行を除去する編集を行っているので、起票者が提案する修正を行っても回避できなかったように思われる。--Freetrashbox会話) 2020年12月29日 (火) 02:38 (UTC)[]
編集フィルター#55変更履歴一致記録 不許可 不要 正しく動作しているように思われる。ただし動作が少なく有効性はやや疑問。----Freetrashbox会話) 2020年12月29日 (火) 04:19 (UTC)[]
編集フィルター#57変更履歴一致記録 警告、タグ付け ページの作成時のみ発動するので修正不要。--本日晴天会話) 2020年12月26日 (土) 03:53 (UTC)[]
編集フィルター#61変更履歴一致記録 不許可 不要 正しく動作しているように思われる。ただし動作が少なく有効性はやや疑問。----Freetrashbox会話) 2020年12月29日 (火) 04:19 (UTC)[]
編集フィルター#62変更履歴一致記録 不許可
編集フィルター#63変更履歴一致記録
編集フィルター#65変更履歴一致記録 不許可 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#66変更履歴一致記録 不許可 不要 少なくともこの1年は正しく動作しているように思われる。----Freetrashbox会話) 2020年12月29日 (火) 04:19 (UTC)[]
編集フィルター#67変更履歴一致記録 不許可 要 過去に誤検出が多くされていたが、途中の版で修正されてからは問題が無くなっている。しかしその修正後に動作記録が無く、有効性は疑問。----Freetrashbox会話) 2020年12月29日 (火) 04:19 (UTC)[] 当該LTAの活動停止と動作記録の少なさにより一旦無効化しました。--ネイ会話) 2020年12月29日 (火) 04:47 (UTC)[]
編集フィルター#70変更履歴一致記録 警告
編集フィルター#71変更履歴一致記録 不許可 フィルター#71の第2467版差分
キーワード追加に際して、同時に対処しました。--えのきだたもつ会話) 2021年1月25日 (月) 12:54 (UTC)[]
編集フィルター#72変更履歴一致記録
編集フィルター#73変更履歴一致記録
編集フィルター#74変更履歴一致記録
編集フィルター#75変更履歴一致記録
編集フィルター#77変更履歴一致記録 不許可 3年間の検出数が1回だけなので、実効のないフィルターとして無効化しました。--ネイ会話) 2020年12月29日 (火) 04:47 (UTC)[]
編集フィルター#79変更履歴一致記録
編集フィルター#80変更履歴一致記録 タグ付け
編集フィルター#84変更履歴一致記録 不許可 3年間の検出数が1回だけなので、実効のないフィルターとして無効化しました。--ネイ会話) 2020年12月29日 (火) 04:47 (UTC)[]
編集フィルター#86変更履歴一致記録 不許可 当該LTAが活動を停止している上、前回の発動が2年前なので、一旦無効化しました。--ネイ会話) 2020年12月29日 (火) 04:47 (UTC)[]
編集フィルター#87変更履歴一致記録
編集フィルター#90変更履歴一致記録 不許可
編集フィルター#92変更履歴一致記録 不許可
編集フィルター#93変更履歴一致記録 不許可
編集フィルター#97変更履歴一致記録 不許可
編集フィルター#100変更履歴一致記録 不許可 前回の発動が2年前なので、実効がなくなったものとして無効化しました。--ネイ会話) 2020年12月31日 (木) 04:28 (UTC)[]
編集フィルター#102変更履歴一致記録 不許可 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)
この編集は誤動作のように思われるが、直後にこのフィルターの主編集者により修正が行われており、LTA対策であることを考えるとやむをえないように思われる。--Freetrashbox会話) 2020年12月28日 (月) 21:50 (UTC)[]
編集フィルター#104変更履歴一致記録 不許可
編集フィルター#109変更履歴一致記録 不許可
編集フィルター#110変更履歴一致記録 不許可
編集フィルター#111変更履歴一致記録 不許可
編集フィルター#113変更履歴一致記録 不許可 2年間の検出数が0回なので、実効のないフィルターとして無効化しました。--ネイ会話) 2020年12月29日 (火) 04:47 (UTC)[]
編集フィルター#114変更履歴一致記録 不許可
編集フィルター#116変更履歴一致記録 不許可 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#118変更履歴一致記録 不許可
編集フィルター#119変更履歴一致記録 不許可
編集フィルター#121変更履歴一致記録 不許可 構文の修正が必要。ただし、以前活発だったLTA用のため廃止(削除)で良いと思う。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[] 無効化・削除を行いました。--Taisyo会話) 2020年12月29日 (火) 05:06 (UTC)[]
編集フィルター#123変更履歴一致記録 不許可 発動回数と対象ページ数が少なく、今後再発した場合でもページの保護で対応すべきとして無効化しました。--ネイ会話) 2020年12月31日 (木) 04:28 (UTC)[]
編集フィルター#124変更履歴一致記録 不許可
編集フィルター#125変更履歴一致記録 不許可 修正不要。(下記コメントでの回答を受け)常時監視・メンテナンスしているため。また、複数条件の組み合わせをしており、除外ワードを設定し誤作動対策も行っている。--えのきだたもつ会話) 2021年1月1日 (金) 15:11 (UTC)[]
編集フィルター#126変更履歴一致記録 不許可 修正不要。既にadded_linesとremoved_linesの両方をチェックしている。--えのきだたもつ会話) 2020年12月28日 (月) 06:26 (UTC)[]
編集フィルター#127変更履歴一致記録 不許可
編集フィルター#128変更履歴一致記録 不許可
編集フィルター#129変更履歴一致記録 不許可 対象が1記事だけなので、編集フィルターではなく保護で対応すべきでは?--ネイ会話) 2020年12月29日 (火) 05:13 (UTC)
半保護以上全保護未満(半保護突破系荒らし)の対応として一時は有用だったと思います。しかし、最近は拡張半保護が実装されたのでそちらでの対応で大丈夫だと思います。--Taisyo会話) 2021年1月1日 (金) 00:42 (UTC)[]
無効化しました。--ネイ会話) 2020年12月31日 (木) 04:28 (UTC)[]
編集フィルター#130変更履歴一致記録 不許可
編集フィルター#131変更履歴一致記録 不許可 対象ページ数が4件、発動回数が0回なので、無効化しました。--ネイ会話) 2020年12月31日 (木) 04:28 (UTC)[]
編集フィルター#133変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#134変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#135変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#136変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#137変更履歴一致記録 不許可 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#138変更履歴一致記録 不許可
編集フィルター#139変更履歴一致記録 不許可 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#140変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[]
編集フィルター#143変更履歴一致記録 不許可、自動昇格を防止 構文の修正が必要。ただし、他のフィルターで対応できているため廃止(削除)で良いと思う。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[] 無効化・削除を行いました。--Taisyo会話) 2020年12月29日 (火) 05:06 (UTC)[]
編集フィルター#145変更履歴一致記録 修正不要 (個人用試験フィルター)--miya会話) 2020年12月27日 (日) 04:46 (UTC)[]
編集フィルター#147変更履歴一致記録 不許可 修正不要。(下記コメントでの回答を受け)常時監視・メンテナンスしているため。また、contains_anyでなくrlikeで正規表現の組み合わせでチェックしている。--えのきだたもつ会話) 2021年1月1日 (金) 15:11 (UTC)[]
編集フィルター#148変更履歴一致記録 不許可 修正不要。(下記コメントでの回答を受け)常時監視・メンテナンスしているため。また、contains_anyでなくrlikeで正規表現の組み合わせでチェックしている。--えのきだたもつ会話) 2021年1月1日 (金) 15:11 (UTC)[]
編集フィルター#149変更履歴一致記録 不許可 構文の修正が必要。ただし、以前活発だったLTA用のため廃止(削除)で良いと思う。--Taisyo会話) 2020年12月27日 (日) 05:32 (UTC)[] 無効化を行いました。再活発化を想定して削除していません。--Taisyo会話) 2020年12月29日 (火) 05:06 (UTC)[]
編集フィルター#155変更履歴一致記録 不許可 修正不要。(下記コメントでの回答を受け)常時監視・メンテナンスしているため。また、contains_anyでなくrlikeで正規表現の組み合わせでチェックしている。--えのきだたもつ会話) 2021年1月1日 (金) 15:11 (UTC)[]

各セルに

  • 修正の要・不要確認(不要な例:キーワード系ではない/意図して行単位条件になっている、など。先述の通り、例であげたコードそのままだけではなく同様の機能を使ったコード全てが修正が必要な対象です)
  • 修正の完了報告({{編集フィルター履歴}}をつけて)

をそれぞれ署名付きでお願いします。 どちらかだけでも、両方ともでも構いませんが、判断に迷う場合、フィルター作成者or直近の編集者にフィルターの意図や仕様などを問い合わせたほうがいいかもしれません。 その問い合わせの手間を考えると、可能であれば自分が作成したor詳しいフィルターは自分自身で確認&修正が望ましいと思います。

緊急で無理してでも今すぐというほどの必要性はないと思いますが、対処が遅れれば遅れるほどjawpコミュニティーから編集フィルター(の編集者)への信用度が低下し続けますので、できる範囲で少しずつでも進めていきましょう。

編集フィルター(ひいてはjawp)の未来は、編集者各位(私も含めて)の腕にかかっています。対応よろしくお願いします。 質疑・コメント等は以下へお願いします。--青子守歌会話/履歴 2020年12月26日 (土) 02:53 (UTC)[]

質疑・コメント編集

コメントします。

  • 上記の内容は理解しました。私個人については、当面は編集フィルターを編集する予定はないので、編集権限を除去頂いてもかまいません。
  • 上記の提案を通すのであれば、「Wikipedia:編集フィルター/作り方」等に、避けるべきコードの例を書いておくべきように思います。過去の議論を全部読まなければフィルター編集者になれない、という状況は避けるべきように思います。

--Freetrashbox会話) 2020年12月26日 (土) 05:10 (UTC)[]

  • (追記)「修正要」と判断された場合は、判断した理由(さらに実際に誤作動したのか、誤作動しうるということか)と、できれば誤作動の例を差分で示して頂けるとわかりやすいと思います。--Freetrashbox会話) 2020年12月26日 (土) 23:18 (UTC)[]
  • (追記) いくつかチェックしてみたところ、アルゴリズムの問題というよりは、フィルターの保守の問題であるように思われます。ちゃんと保守が行われているフィルターであれば青子守歌さんが指摘するような文になっていても大きな問題はなさそうに思えます。また、編集フィルター#22などは青子守歌さん自身が比較的主要な編集をしているように思われますが、典型的な誤動作をしており、青子守歌さんでもうっかりするような構文上のミスをフィルター編集者全員に求めるのは少し酷なようにも思います(この編集が問題ないのであれば、提案の問題点をもう少し詳しく説明してもらえると助かります)。--Freetrashbox会話) 2020年12月28日 (月) 21:50 (UTC)[]
  • (追記) フィルター#126のように記載すればいいんですかね?#126は記載が大変読みやすいです。「模範例」を挙げて貰った方が改定が進むように思います。書き直したソースのダメ出しされるのは辛い。--Freetrashbox会話) 2020年12月29日 (火) 23:29 (UTC)[]
    • @Freetrashbox: 模範例は既に冒頭に書いた通り(added|removed)_linesを両方確認する以上はないのですけれども、具体例をということでフィルター#17の第2423版差分)を修正しました。例えば、要不要コメントにある特別:不正利用記録/1327626はこれで条件一致しなくなりますが、(意図が正しいかはおいといて)意図通りと考えられる特別:不正利用記録/1306000はこれまで通り条件一致します(それぞれに対して#17を試験すれば確認できます)。--青子守歌会話/履歴 2020年12月30日 (水) 03:21 (UTC)[]
      • 例示、ありがとうございます。なるほど、変数も使えるんですね。#126のように同じ単語を2回並べるのはバグの遠因になると感じたので、確認できてよかったです。--Freetrashbox会話) 2020年12月30日 (水) 03:32 (UTC)[]
        •   コメント contains_anyに関してですが、配列変数に対応しているのは第1引数(通常added_linesやremoved_linesなどを書きます)だけで、第2引数以降は対応していないので、例えば、
keywords := ["A", "B", "C"];
contains_any(added_lines, keywords) & !contains_any(removed_lines, keywords)
の様なコードを書いても正常動作しませんので、第2引数以降に列挙するしかなく、現状のコードになります。回避策をご存知の方がおられましたら教えて下さい。--えのきだたもつ会話) 2020年12月31日 (木) 09:12 (UTC)[]
  • 変数が使えないのであれば、少なくとも複雑な構文のフィルターについては、安易に変えない方がいいかもしれませんね。--Freetrashbox会話) 2021年1月1日 (金) 01:53 (UTC)[]

  コメント 非公開フィルターの内容確認が目的でフィルター権限をつけっぱなしにしているだけで、構文の知識はほとんど持たない者ですが、いくつか順番に見てみました。

  • 上の表についてですが、「要・不要」が何を意味するか、「修正の要・不要」なのか、それとも「フィルターの要・不要」なのか、分かりにくいです。(Taisyoさんは「フィルターの要・不要」とお考えなんじゃないでしょうか?)
  • 上の表にフィルター作成者の欄を設けて、作成者の意見も書いてもらってはどうでしょう?
  • ( rmwhitespace(added_lines) rlike rmwhitespace(" とか  ( rmwhitespace(added_lines) rlike rmwhitespace(" & contains_any(lcase(added_lines),は問題ないのでしょうか?(不勉強ですみません)
  • 途中まで見て回ったのですが(ちょっと本件からは外れますが)特別:不正利用フィルター/15特別:不正利用フィルター/50は、なぜ非公開フィルターなのか、疑問に思いました。#50はWikipedia:編集フィルター/一覧にも見つかりませんし。

--miya会話) 2020年12月26日 (土) 12:41 (UTC) 訂正:コピペミスがあった箇所に修正を入れました。--miya会話) 2020年12月26日 (土) 13:48 (UTC)[]

私向けのメッセージがあったので。確かに「実際に使っているかどうか」「実際に有効性があるかどうか」のコメントです。修正の必要・不要では見ていないです。元の構文(今回は禁句系フィルターの元)を作るのは正直に難しいです。半面、引っ掛けるワードを考えるのは、結構有効なワードを見つけています。あとのコメントにもつながるのですが、構文が分からない人でも「本文or概要、両方か」、「反応させる編集数」・「引っ掛けたいワード」を入れたら簡単に動く「禁句系フィルター」を用意した方が良いのではと思います(できたとして、移行をどうするかの問題はありますが)。--Taisyo会話) 2020年12月26日 (土) 13:02 (UTC)[]
@Miya and Taisyo: 表の下の「こういう風に書いてください」というお願いにちゃんと書いてある通り、また、本日の晴天さんや私の前例通り、その列では修正の要・不要を求めています。なぜならここは「フィルターを修正する必要がある」という変更提案の場であって、フィルターを廃止するという話は別にしていませんので(廃止しても良いから修正不要、という話ならそれはそれで良いと思いますが)。というわけで、もし間違った意味で書いてしまっていたのなら、修正あるいは除去してもらえますか。表の方にも間違えないように明記しました。--青子守歌会話/履歴 2020年12月26日 (土) 13:19 (UTC)[]
了解しました。削除時の偽陽性反応問題の対応で、構文問題であることを理解しました。そのあと、この様な目線でのコメントに書き換えます。だた、偽陽性判定も問題ではありますが、いくつか見ていて他の問題点も見つけました。
  • 現在使用していない(極端な話削除済も)の同様のフィルターも、コピペによる拡散防止のために正しい公文に書き換えるべきでは。
  • 数が多いのは仕方ないにしても、同じ目的のフィルターが複数ある場合があるので、まとめた上で廃止フィルターを削除するべきでは。
削除時の偽陽性を含め、他に考えられる対応を行った方が、さらに良いのではと思います。--Taisyo会話) 2020年12月27日 (日) 05:19 (UTC)[]
@Miya: rmwhitespaceやlcaseは引数の文字列を置換するだけの関数なので、問題があることに変わりありません。投稿者が追加除去していないキーワードが含まれているのは同じですので。--青子守歌会話/履歴 2020年12月28日 (月) 01:14 (UTC)[]

  コメント 禁句系フィルターは上手に使えば、記事の保護やIPのブロック数など減らすことが出来るなど有効な側面もあります。また、個人名をばらまく、いわゆる「知能知数が低いと思われる事が原因のLTA」には相当有効(そうしないと抑止力が無い)です。構文ミスを防ぐ側面もあり、2015年7月17日のフィルター37の不具合時に「簡単に運用できる禁句系フィルター機能」の実装をお願いした記憶があります。しかし、「メタに要望しています」や「お願いしましたが出来ませんでした」など、連絡はいただけておりません。今でも、「簡単に運用できる禁句系フィルター」の実装をお願いしておりますので、今からでも良いので、動いてもらえないでしょうか。実際の動作状況は、フィルター37の不具合以降は、目に見える形での大規模不具合は起こしていないはずです。--Taisyo会話) 2020年12月26日 (土) 12:54 (UTC)[]

  • 優先して修正すべきなのは投稿が差し止められる(かつ無効化されていない)フィルターあたりでしょうか。対処操作が何も付いてないフィルターは当面放置しても実害はほぼないだろうと思います。[5]から「対処操作」の列をコピーしておきました(ただし、あくまで現時点の対処操作を記しているだけなので、今後フィルターが変更されれば齟齬が出るかもしれません)。 --whym会話) 2020年12月27日 (日) 11:43 (UTC)[]

  •   コメント フィルター126ですが、禁句ワード加筆(主に悪戯)を有効に検出しているのに、フィルター内のメモにも書いてありますが、誤動作の多さを理由に「不許可」が外されていました。確かに誤動作もありましたが、毎日の様に検出される(悪戯加筆が行われる)のに不許可に出来ないものかと、本提案前でしたが、2020-10-22にadded_linesに加えremoved_linesにない事もチェックする様に修正し、かつ禁句ワードを含む正常ワードを辞書等で調べて上げて除外ワードとする処理も加え誤作動の防止を強化し、試運用ののち2020-10-29に不許可を復活させました。その甲斐もあってか、毎日の様に行われる悪戯投稿を有効に不許可に出来ております。それでも、思いもよらない禁句ワードを含む正常ワードは出て来る(作品特有ワードが多いです)ので、毎日数回の「編集フィルター記録」のチェックは欠かさず続けており、メンテナンスは怠っておりません。
  • この様に誤動作防止の為には、added_linesとremoved_linesの両方をチェックするだけでなく、禁句ワードを含む正常ワードを除外ワードとする処理も状況によっては必要ではないでしょうか?また、特に現在「編集フィルター記録」で動作が確認出来る不許可フィルターについては、作成者または編集者が、毎日(私は一日数回行っていますが、最低1日1回)のチェックを行い、誤動作の早期発見と早期対応を行うべきかと思います。
  • contains_anyでadded_linesとremoved_linesの両方をチェックするという事は、検索が2倍になるという事で、単純計算で動作時間が2倍になるという事になります。contains_anyは負荷が重く避けるべき関数とはされていませんが、最終的な対処フィルター数は分かりませんが、数多くのフィルターで対処が行われた場合、フィルター全体の動作時間のシステムへの負荷の増加は大丈夫なのでしょうか?
  • 本提案とは別件になりますが、先日あるLTAの問題加筆ワードを不許可に出来ないかと、それを行っている既存フィルターがないかと、全フィルターを見て探していたときに思ったのですが、現在「編集フィルター記録」を見ても動作状況を見ても、しばらくの間全く動作していないフィルターも見受けられたので、急ぎではありませんが、これらの整理(削除)も負荷軽減の為にも必要ではないかと思いました。--えのきだたもつ会話) 2020年12月28日 (月) 06:08 (UTC)[]
    読んで少し言葉が足りなかったかと思ったので、謝罪と補足をさせてください。ここで↑にあげたフィルターおよびフィルター編集者が全て悪いとは言うつもりはありません。誤解を招く表現だったかもしれず、そこはお詫びします。補足するならば、「今回指摘されたような問題が含まれている」フィルターと、「そのような問題のあるフィルターの管理を放置して誤作動を見過ごした」フィルター編集者に責任と努力不足があるということです(後者の「見過ごし」という意味では相互監視すべき全員の問題という意味はあると、これは先に述べたとおりです)。列挙されているのはそれら問題を含む可能性がある候補の一覧であり、こえこそ偽陽性を多分に含みます。もし、えのきだたもつさんを含む適切に管理・修正をかけているフィルター編集者が管理しているフィルターについては、そのままで問題ないのであれば「修正不要」と報告いただければ十分だと思います。--青子守歌会話/履歴 2020年12月28日 (月) 14:39 (UTC)[]
  •   コメント 15番は作成時の議論では「どの部分を残せば発動しないかと言う事があるので、非公開であるべきである」との意見がありますが、現時点でのフィルターで発動しなければ「削除依頼テンプレートの除去編集」と言えなくなると思います。したがって、「どの部分を残せば発動しないか」の秘匿に意味はないと考えます。
  • 3ヶ月程度経過しても署名されていない場合は、(中略)フィルター編集権限の除去依頼を出す」ことに反対します(「反対票を投じる」という意味で捉えてください)。Wikipedia:編集フィルター/権限付与の申請では「一定期間、活動がとまっている」としか書かれていないので、議論もなしに「一定期間」をかなり短い3か月間に定めていると捉えられかねないためです。悪用された場合の危険性がより高いインターフェース管理者は6か月と定められているので、「一定期間」が常識的に3か月間を指すとは言えませんし、編集フィルター編集者の規定がインターフェース管理者よりも厳しい理由も説明されていません(したがって、この議論を合意形成として扱っても現状では反対します)。なお、これを機に編集フィルター編集者の自動退任を定める合意形成を行うことには賛成し、合意形成を行わない場合でも(削除者とボットフラグと同等の)1年後に除去依頼を出すことには賛成します。--ネイ会話) 2020年12月28日 (月) 12:36 (UTC)[]
  •   15番は作成時には非公開で提案しましたが、現在は当時とは状況も内容も変化しているため、公開とすることに反対しません。  除去提案を行うことについても、最終的にはコミュニティの意見に基づいて除去が判断されることになるため、それ自体には反対はしません。しかし、3か月という短い期間設定や、反応がなければ全員一律で除去提案を行うということは少々強引な印象を受けます。例えばオーバーサイトであるPenn Stationさん、Infinite0694さんについては、仮に今後反応がなかったとしても、非公開フィルター履歴へのオーバーサイトが不可能になる&他のオーバーサイトによる秘匿処理の正当性を監視できなくなるという点において、除去には強く反対せざるをえません。(非公開フィルターの検知履歴は、管理者権限のみでは閲覧できません(参考リンク)。一般利用者にも閲覧できないためオーバーサイト実施の優先度は下がりますが、編集フィルター編集者には依然閲覧可能な状態となるため、方針に該当する記述があれば秘匿処理を行うことになります。)オーバーサイトでなくても、管理者と兼任する方であれば、荒らし対応の参考に非公開フィルターの内容や履歴を閲覧したい方はいるはずです。なお、編集者権限は編集目的の保持に限るべきと考える方が多いならば、今後管理者には「abusefilter-view-private」権限を設定することは一つの選択肢になるかもしれません。--W.CC会話) 2020年12月28日 (月) 13:52 (UTC)[]
    まず最初に、3ヶ月という期間に別にこだわりがあるわけではないので、半年でも1年でもなんでもいいんですけれども。ここで私が求めたのは「フィルター編集者がフィルターを編集するに当たって当然知っておくべきことを通知するので、ちゃんと応答(署名)してね」という至極単純なことです。しかもpingで通知までされている中で、見落としがないように注意も払ってます。その状況下ですら短い応答もできないのであれば、そのような人が、今後もフィルターを正しく作成・編集し、かつログを定期確認してコードを管理してバグ報告もちゃんと読んで応答して、ということが出来るのかはかなり疑問です。完璧にやれとは誰も言ってません(私もできてませんから)。しかし重大な問題があったという報告下で、最低限の要望として「うん、分かったよ。今後は気をつけるよ」の一言を求めていることに、そこまで目くじら立てて「やりすぎ」と主張する気持ちに、逆に私は理解が及びません。権限保持の目的がログ閲覧目的かどうか、それによって応答に「編集しないから関係ないよ」が含まれているかは知りようがないのでどっちでもいいとして、なんにせよ管理者権限と同程度の非公開情報を閲覧できることから管理者と同じく同等の「3ヶ月」、という期間がそんな大騒ぎするような設定なんでしょうかね…。最初に書いた通り、期間とかは些事であって、もちろん不活性な人を辞めさせるかどうかも自転車置き場の屋根の色程度の話であって、重要なことは既存+今後のフィルターが正しくバグなく修正&作成されることですので、それが達成・促進できる代案があるなら期間延長でもなんでも議事を進めていただければ助かります。--青子守歌会話/履歴 2020年12月28日 (月) 14:29 (UTC)[]
ひとまず、3か月という設定にこだわりがないとのことで安心しました。私もご提案の趣旨や目的には賛成しております。オーバーサイトのお2人に対する除去反対を除けば、「そこまで目くじら立てて「やりすぎ」と主張する」ほどのことをしたつもりはないのですが、そのように伝わってしまったのであれば申し訳なく思います。幅広く活動していらっしゃる青子守歌さんにおかれましては十分ご存じのことと思いますが、強い言葉を使えば強い反応が返ってくることは自然なことですので、表現にはご配慮いただければと思います。--W.CC会話) 2020年12月28日 (月) 14:55 (UTC)[]
【署名について】「理解した方は署名を書いてください」と「理解するまでフィルターの編集は控えてください」を切り分けてほしいです。つまり
  • 「読んだら署名してください」
  • 「完全に理解するまでフィルター編集は控えてください」
を分けてほしいのです。私はご意見の趣旨は理解しましたが「気になる点・不明点・コメントなどあれば本節末尾で解決してから署名をお願いします」と言われたら署名できません。--miya会話) 2020年12月29日 (火) 01:25 (UTC)[]
署名する=理解する=フィルターの編集ができるようになる、という等式を分離することは出来ないと思います。まず「単に読んだら署名」というのは良くなくて(最初そう書いてましたが気づいたのでやめた)、「なんだか分からんけど読んだからヨシ」みたいなのは困るわけです。この段階で署名されても何の意味もなくて、何が求められているのかが分からないなら(他の人も同じことで困ってるかもしれないので公開の場で)聞いて、自分の腑に落ちてから署名してもらう必要があります。署名の理由は、「署名した=この問題を起こさないようにします」という宣言をしてほしいという意味であって、署名してからでないとフィルターの編集をしないでくれというのはここから来てます。先述の通り「問題を起こさないです」に「俺はログの閲覧しかしないから」が含まれているかは(知りようがないので)不問です。このように、これらは全部同時に起きるはずなので、分けても意味がないと思うのですけれども…?--青子守歌会話/履歴 2020年12月30日 (水) 04:16 (UTC)[]
「署名した=この問題を起こさないようにします」という宣言をしてほしいという意味とのこと、了解しました。--miya会話) 2021年2月6日 (土) 09:21 (UTC)[]
  •   フィルター#22ですが、警告の際に表示されるメッセージで、誤爆の可能性と、フィルター発動の条件になるマジックワードの仕様に関する調査をお願いする文言を挿入しています。おぼろげながらですが、ここで言われている典型的な誤作動に気が付いて、その当時はそのような仕様であると判断したのと、マジックワードが多用されている状況に対する抑止力のようなものを期待して警告文書に文言を入れたような感じだと思っています。修正対象の文書であるかどうかに限らず、#22で検知対象としているマジックワードは標準記事空間での使用は極力回避すべきと考えているので、現行のままで置いておくのも一つの手段ではないかと思いますが、「誤作動をなくす」ことを最終目標とすることに強い合意があるのであれば、そちらを優先することに異存はありません。--VZP10224会話) 2020年12月31日 (木) 08:49 (UTC)[]
  •   修正するにしても、修正を行ったことで構文を間違えたことでの誤動作を防止するために、構文の修正を一時的にはありますが見送っています。具体的な構文が欲しい側面もあります。曲りなりに誤動作なく(潜在的な誤動作リスクはありますが)有用に動いているので、一定間隔で動作チェックはしていますので、一時的な未修正が大きな問題になることは無いと思います。荒らし利用者に「編集フィルターやめるから、荒らし行為やめてね」なんてことは出来ませんし。--Taisyo会話) 2021年1月1日 (金) 01:17 (UTC)[]
    • 私も、現状おおむね問題が無く、管理する人がいるフィルターに関しては、現状維持でよいと思います。前にも書いた通り、今回提案された方法でも誤作動を完全に防ぐことはできないので、従来通り、有用性と無害性を比較した上での小まめな調整が一番かと思います。--Freetrashbox会話) 2021年1月1日 (金) 01:53 (UTC)[]
    • 補足説明。私自身は長い目で見たら直すべきの立場も取っています。提案内容にもある誤動作のリスクは確かにありますので、(0に出来ないにしても)誤動作リスクの軽減は一定の理解はできます。ただ、不確かな修正を行うことでフィルターの有効性が無くなったり、別の意味での誤動作を起こす可能性も存在しています。5年前に青子守歌さんが「誤動作内容に必要なチェックを」と言われて、実際に行っています。また、誤動作があるにしても、引っ掛ける言葉の工夫で誤動作回避を実際には既に行っている場合もあります。修正に伴う誤動作と発生と、監視することでの軽減。提案者の青子守歌さんが、モデルフィルターを作って対応してもと思います。先にも言いましたが、私は5年前に「誤動作の少ない禁句系フィルターの作成のお願い」をしております。これだけ多いということは、日本語版の荒らし対応に有効であると認められているといったところです。別に編集フィルターが特権階級のものとも思いません(青子守歌さんはそんなことを言っていたような気がします)。使える道具はどんどん使っていくべきです。半保護にも限界はありますし、全保護してしまうと記事の発展は止まってしまいます。拡張半保護は最近出来ましたが、禁句系フィルターは結構有効なのです。ヘタな修正をしないように、様子を見ている部分もありますし、別に信用無くすことはしてないぞと言いたいです。--Taisyo会話) 2021年1月3日 (日) 03:47 (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)[]
先にフィルターの公開提案を出すので、こちらは一旦保留(公開提案が決着した後に再開)ということで。--ネイ会話) 2020年12月29日 (火) 05:40 (UTC)[]

#15を公開する提案編集

「「追加除去キーワード一致」系の編集フィルターはキーワードが追加除去されていない場合に発動しないように正しく設定する」の節でも提起されたことですが、編集フィルター#15変更履歴一致記録(削除依頼テンプレートの除去)は非公開になっています。現行版では非公開にする必要がなさそうです。作成時の議論では「どの部分を残せば発動しないかと言う事があるので、非公開であるべきである」との意見がありましたが、現行版ではそのような問題がなくなっています(フィルターが発動しなければ、削除依頼テンプレートの除去をしていないと言える)。したがって、フィルターの公開を提案します。--ネイ会話) 2020年12月29日 (火) 05:40 (UTC)[]

半年以上経過しましたが、反対はありませんでした。これ以上コメントがなければ、1週間後をめどにフィルターを公開します。--ネイ会話) 2021年7月24日 (土) 06:09 (UTC)[]

#12でグローバル利用者名変更者に関する条件を外す提案編集

編集フィルター#12変更履歴一致記録新規利用者による他利用者ページの編集)はグローバル利用者名変更者による編集を除外する必要がありました。しかし、利用者名変更操作に伴うページ移動はphab:T212082での修正(2019年9月)により編集フィルターにかからなくなったため、除外の必要がなくなりました。したがって、当該条件の除去を提案します。--ネイ会話) 2020年12月29日 (火) 05:45 (UTC)[]

半年以上経過しましたが、反対はありませんでした。これ以上コメントがなければ、1週間後をめどに編集します。--ネイ会話) 2021年7月24日 (土) 06:15 (UTC)[]

ログ編集