「Wikipedia:編集フィルター/提案」の版間の差分
削除された内容 追加された内容
→「追加除去キーワード一致」系の編集フィルターはキーワードが追加除去されていない場合に発動しないように正しく設定する: 無効化4件（100、123、129、131） |
→半保護突破のための編集数稼ぎ防止: Tの閾値公開だけは妥協できません。 |
||
| 411行目: | 411行目: | ||
::Loasaさんの仕様案を元に「閾値を非公開にする」のであれば、良いのではと思います。[[利用者:Q8j|Q8j]]さんの指摘の通りです。閾値がバレた時点で、それを狙って編集するだけなのではと思います。やはり、ある程度は心理戦の部分があり、極端に厳しくすると誤爆が増えるリスクが大きいです。そうしないためには、柔軟に閾値を変えた上で、非公表にするが一番実効性が高いと思います。 |
::Loasaさんの仕様案を元に「閾値を非公開にする」のであれば、良いのではと思います。[[利用者:Q8j|Q8j]]さんの指摘の通りです。閾値がバレた時点で、それを狙って編集するだけなのではと思います。やはり、ある程度は心理戦の部分があり、極端に厳しくすると誤爆が増えるリスクが大きいです。そうしないためには、柔軟に閾値を変えた上で、非公表にするが一番実効性が高いと思います。 |
||
::対象LTAについても、指摘の通り[[LTA:ASPE]]については、特に荒らす記事を拡張半保護。[[LTA:Iccic]]は薄々は気が付いているのだけど・・・状態で[[LTA:203]]対策に限定で良い様に思います。提案時と半保護の仕様が変わったのは大きいです。--[[利用者:Taisyo|Taisyo]]（[[利用者‐会話:Taisyo|会話]]） 2020年9月11日 (金) 10:49 (UTC) |
::対象LTAについても、指摘の通り[[LTA:ASPE]]については、特に荒らす記事を拡張半保護。[[LTA:Iccic]]は薄々は気が付いているのだけど・・・状態で[[LTA:203]]対策に限定で良い様に思います。提案時と半保護の仕様が変わったのは大きいです。--[[利用者:Taisyo|Taisyo]]（[[利用者‐会話:Taisyo|会話]]） 2020年9月11日 (金) 10:49 (UTC) |
||
* コメントが遅くなってすみません。私の意見は[[特別:差分/77290891]]の後半で述べたことがすべてですが、もう少し演説します。フィルタに限らずこの種の防御システムは、その効用や緊急性・重大性と副作用のバランスで考えるべきです。たとえば、その防御システムが対象とする問題行為が、ウィキペディアに対して致命的といえるほど重大な損害を与えるようなものであり（重大性）、かつ、緊急な対策を要するものでもあり（緊急性）、かつ、その防御システムがその行為に対する阻止として有効に働く(効用）ものであるならば、若干の副作用はやむを得ないでしょう。しかし本フィルタの対象とする問題行為は、そこまでしなければならないほど緊急性や重大性の高いものではありません。有効性という点でも（パラメーターを非公開にしたとしても）上でコメントされているようにいずれは突破されてしまうだろうし、多少時間をかければフィルターの意味もなさなくなる可能性が高いものです。本フィルタの効果はその程度しか期待できないのに対して、無関係な初心者が引っかかる確率がほぼ１００％であり、しかも短時間とはいえ、ブロックの可能性もあるというリスクは効果に見合ったものとはいえません。そして、フィルタの仕様上、非常に高い確率で無関係な初心者が引っかかる可能性は避けられません。ならばせめて副作用が発生したときの救済措置を十二分に用意しておく必要があります。私の考えではその救済措置の一つがパラメーターの閾値公開なのです。初心者が引っかかったときにT時間待てば自動的に回復できる、とわかるだけでも安心できます。たとえ短時間でもそれがわからないのは非常な不安になるものです。 |
|||
:そのようなわけで、細かい仕様はお任せしてもよいのですが、パラメーターの閾値公開だけは絶対的な条件とします。ただ、多少は妥協して、NやBに関しては非公開でもよいでしょう。公開するのは最大ブロック可能時間、すなわちTの最大値だけでもよいとします。Tの最大値の公開すら駄目ということであれば、このフィルタは有用性のわりに副作用の害が大きすぎるということで、フィルタの作成自体に反対とさせていただきます。パラメーターTの最大値の公開すら認められない、ということであれば、それならばこのフィルタを作るのは止めましょう、というのが私の最終的な結論です。--[[利用者:Loasa|Loasa]]（[[利用者‐会話:Loasa|会話]]） 2020年12月31日 (木) 07:18 (UTC) |
|||
===不適切なリダイレクトの作成防止 === |
===不適切なリダイレクトの作成防止 === |
||
2020年12月31日 (木) 07:18時点における版
 | Wikipedia‐ノート:編集フィルター#フィルターによるブロック機能についてに、このページに関する相談があります。（2021年3月） 相談の要約：ブロック機能を有効化することの是非 |
 |
ここは、新しい編集フィルターの作成や、既存のフィルターの（大幅な）仕様変更について、議論したり提案したりするページです。
原則として、新しいフィルターはここで提案し合意形成の後に作成するようにしてください。 やむを得ず合意形成をすることが出来ないまま作成されたフィルターについても、その狙いなどを報告をするように努めてください。
提案と作成
フィルターを提案する前に
Wikipedia:編集フィルター/一覧を参照し、同じ機能のものが既にないか確認してください。
また、フィルターの機能について以下の点に留意してください。
- フィルターはすべての編集を対象とします。それゆえに、例えば、単一ページに加えられた問題のある編集への対処には、編集フィルターの利用は向かないでしょう。
- フィルターはどれも作動に時間をとるので、編集が（およびその他も多少）若干ながら遅くなります。一つのフィルターにつき数ミリ秒程度遅くなるだけですが、フィルターが増えれば合算でそこそこになりえます。
- フィルターがチェックできることには限界があります。もっと複雑で必要不可欠ではない機能（たとえば、ページ内容を掘り下げたチェックが必要な場合や、フィルターシステムでは取得できない情報を必要とする場合など）は、個人のコンピュータやツールサーバ上で別のソフトウェアを用いて行う方がよいでしょう。
新しく提案するには
新しい提案は「提案中のフィルター」の一番上に次の形式で追加してください。
=== フィルターの名前 ===
{{編集フィルター提案|提案中
|目的 = <!-- どんなページ、もしくはどんな利用者に、どんな働きをするフィルターか -->
|理由 = <!-- このフィルターが必要な理由 -->
}}
--~~~~ <!-- 署名を忘れずに！ -->
目的にはそのフィルターの動作仕様、理由にはその動作が必要な理由を書いてください。
具体的なフィルターの発動条件などの提案は歓迎されますが、フィルターの提案するにあたって絶対に必要ではありません。 特に、明確な悪意を持った荒らしに対処するようなフィルターなど、フィルターの詳細を非公開にすべきようなものの場合は、発動条件を詳細に明記し議論しない方が良い場合があるので、注意してください。
新しく提案したものは、テンプレート:編集フィルターの一覧へ載せることができます。
提案から正式稼動までの流れ
以下の手順は草案です。以下の手順に支障や問題、コメントがあればWikipedia‐ノート:編集フィルターで提起してください。
- 新しく提案するにはの手順に従って、新しいフィルターがどんなものか提案してください。
- その作成提案に対して、{{賛成}}や{{反対}}、{{コメント}}、{{問}}などを使って議論し、作成することに対する合意形成をしてください。
- もし、提案後1週間が経過し、2人以上の賛成（提案者の提案者票を含めても良い）があり、かつ反対する人がいない場合は、合意がなされたとみなされます。
- 合意形成がなされたフィルターは、編集フィルター編集者によって新しく作成され、1週間の発動条件の試験と、1週間の対処操作の試験の、合計2週間の試験運用を行ないます。
- 前半の1週間は、発動条件の確認をするための試験が行なわれます。この期間中は、対処操作（ただし、速度制限は発動条件とみなされます）を設定できません。
- 前半の試験期間が問題なく経過すれば、対処操作が付与され、後半の1週間は、対処操作の試験となります。
- 各期間中に問題が発生したあるいは報告された場合は、修正を行ない、期間は修正からさらに1週間延長されます（つまり、修正が加えられると期間はリセットされます）。ただし、反応速度の向上などの微修正の場合は延長する必要はありません。
- 対処操作の試験期間が問題なく経過すれば、試験運用は終了し、フィルターは正式稼働となり、情報はWikipedia:編集フィルター/一覧に過去ログ化されます。
- 正式稼動後に問題が発生した場合は、Wikipedia:編集フィルター/誤作動で報告してください。
非公開フィルターに関する注意
非公開フィルターの作成を提案し議論する場合は、そのフィルターが非公開になる理由によく注意して、慎重に議論あるいは情報提供を行なってください。
特に、明確な悪意を持った荒らしに対処するようなフィルターなどの場合、詳細な発動条件などに関して公開の場で議論を行なうと、そのフィルターの有用性が低下するばかりか、かえって悪用される可能性もあります。
そのフィルターが、本当に非公開にしなければならないような深刻な問題に対するものなのであれば、あなたが詳細を述べなくとも編集フィルター編集者はその意図を十分に汲みとってフィルターを作成してくれるでしょう。
既存フィルターの仕様変更
新しく作成するのではなく、既存のフィルターの動作を大きく変えるような変更、つまり、
- 対処操作の付与と除去
- 通知文の（大幅な）内容の変更
- フィルターの発動対象の操作（発動条件のねらい）の変更
といった、誤作動や誤りなどの訂正でない変更の提案は、仕様変更提案で扱われます。
ログ化
正式稼動もしくはフィルターの作成が合意できなかった提案は、1週間ののち過去ログ化されます。
仕様変更提案は、各フィルターのページに過去ログ化されます。
Wikipedia:編集フィルター/提案/ログをご覧ください。
提案中のフィルター
ソフトリダイレクト防止
提案中
| 目的 | 利用者:アガリ（会話 / 投稿記録 / 記録）のブロック回避による荒らしを防ぐため。 |
|---|---|
| 理由 | 週末（土日）に上記投稿者のブロック回避IPがウィクショナリーへのソフトリダイレクトを多数作成しているため。 |
| 発動条件 | {{Wtr}}や{{Wiktionary redirect}}を含む投稿をした場合。 |
| 対処操作 | 不許可 |
ブロックよりフィルタで対応したほうが良いかと。-- Bule 020（会話） 2020年12月26日 (土) 11:09 (UTC)
- @Bule 020さん
反対 もう少し具体的な案を示していただけませんか？現時点での案だけでは巻き込みが多数発生することが容易に想定されるため、反対としておきます。--Semi-Brace (会話 / 投稿) 2020年12月26日 (土) 13:25 (UTC)
連投対策
提案中
| 目的 | 過度の連続投稿対策 |
|---|---|
| 理由 | 利用者:母語（会話 / 投稿記録 / 記録）のようなタイプの荒らしを防ぐため |
| 発動条件 | 拡張承認された利用者、Bot以外による、1分間に６を超える投稿。 |
| 対処操作 | 不許可 |
詳しくは利用者‐会話:Infinite0694の履歴、Wikipedia‐ノート:井戸端の履歴をご確認ください。今回は今のところあまり大規模なことにはなっていませんが、発生すると対応されるまでの害が甚大なので対応が必要と考えます。action=editに限定されないとしたのは同じことは移動などでも可能だからです。--Q8j（会話） 2020年11月2日 (月) 18:49 (UTC)
コメント 何らかのツールを使っている人は別かもしれませんが、活動開始から3年以上、編集回数2万回を超えている利用者でも9編集/分が限界（Wikipedia:井戸端/subj/複数の記事に投稿するときの間隔について参照）なので、手作業で投稿する限りは不運にもフィルターに引っかかりそうな新規利用者さんはあまりいなさそうには感じます。ただ、いまの条件だと、巻き戻し権限保持者（巻き戻し者・管理者・グローバル巻き戻し者・グローバル管理者・スチュワード）が巻き戻し権限を適切に使用できなくなるリスクがあると思うのですが、どうなのでしょうか（これらの権限保持者が拡張承認された利用者であるとは限りません）。あと、場合によってはLTA:203やLTA: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にも属さないので（私は巻き戻し操作でサイズの大幅な増減などのフィルターに引っかかったことはないです）、この２つに限定すれば巻き戻し対策にもなると思います。--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権限保有者は以下の通りです。
- この方法であればbotの除外も必要ない（botはnoratelimit持ち）ですし、actionを限定する必要もなくなります。１点問題があるとすれば拡張承認されていないインターフェース管理者が誕生した時ですが、まぁその時は手動で拡張承認つければ済みます（そんな滅多に起こらないであろう事態のために条件増やしてフィルター重くするのも良くないですし）。--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)
YouTubeのチャンネルを直接貼った編集のトラック
提案中
| 目的 | {{SD|G4}} が付けられるような記事の作成防止
|
|---|---|
| 理由 | P丸様。（ノート / 履歴 / ログ / リンク元） チャンネルがーどまん（ノート / 履歴 / ログ / リンク元）など、明らかに宣伝が主目的のページを作成される確率を減らす |
| 発動条件 | 新規作成されたページ、標準名前空間、バイト数が1000未満、任意の行に https://www.youtube.com/channel を含むという条件を全て満たす編集 |
| 対処操作 | 警告 |
最近作成されるYouTube(r) 関連の記事で、特筆性のないページのほうが多くなってきたと思われるため上記の通り提案します。--Semi-Brace (会話 / 投稿) 2020年10月31日 (土) 06:39 (UTC)
初版からある修正テンプレートの追跡
提案中
| 目的 | Category:修正テンプレートが貼られたまま作成されるページの検出 |
|---|---|
| 理由 | そもそも修正テンプレートは初版から貼って他人に修正を告知する趣旨で作られていないため。 |
| 発動条件 | 新規作成、かつ作成時のテキストにCategory:修正テンプレートのいずれかの呼び出しが含まれている場合 |
| 対処操作 | タグ付け |
Category:修正テンプレートだと広すぎる気がするのでご意見を募集したいと思います。--Semi-Brace (会話 / 投稿) 2020年10月23日 (金) 06:08 (UTC)
質問 例えばSemi-Braceさんがそのタグがついた編集（作成）を見たら、どうされますか？--Q8j（会話） 2020年11月2日 (月) 19:48 (UTC)
- 基本的にはテンプレートに応じて修正する (例: wikify) ことを試みますが、あまりにも深刻だったり、あるいは明らかに削除の方針に合致する場合は削除依頼へ回付します。主題と場合によっては加筆依頼に出すと思います。なお、翻訳記事の場合はこのフィルターがトリガーされても仕方ないと思います (というのも、翻訳元にそれらのテンプレートが含まれていたらどうしょうもないため) --Semi-Brace (会話 / 投稿) 2020年11月2日 (月) 23:38 (UTC)
- 返信 「基本的にはテンプレートに応じて修正する (例: wikify) ことを試みますが、あまりにも深刻だったり、あるいは明らかに削除の方針に合致する場合は削除依頼へ回付します。主題と場合によっては加筆依頼に出すと思います。」というのはカテゴリーが（他者によって）貼られていた場合と何か違うのでしょうか？--Q8j（会話） 2020年11月4日 (水) 18:56 (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)
白紙化/除去対策
不作成
| 目的 | 単純な荒らし対策 |
|---|---|
| 理由 | ここ数日、ISECHIKAによる大量の白紙化荒らし（例えばこの履歴に複数、利用者名が不可視化されたものがあるのがお分かりいただけると思います）や、それに限らず対話などに全く応じず、ブロックされるまで延々と、すごい勢いで荒らし続ける単純な荒らしの足止めを狙っています。 |
| 発動条件 | 編集回数50回未満の利用者が、30分以内に10回以上、-1000以上の編集を行ったとき |
| コード | edit_delta <= -1000 & user_editcount < 50（と30分以内に10回以上） |
| 対処操作 | 不許可 |
延々と荒らし/リバートが続くのを減らすのが目的です。巻き添えを減らしつつ荒らしの邪魔ができるラインを考えてみました（善良な利用者が30分以内に10回も大量除去するのは考えにくい）。一応バイト数だけを持って荒らしと断定することはできないので、連続投稿はお控えくださいのような案内文にすれば良いかと思います。--Q8j（会話） 2020年7月25日 (土) 10:31 (UTC)コードミス訂正--Q8j（会話） 2020年7月26日 (日) 14:51 (UTC)
- コメント 特定のLTA狙い撃ちの対策に詳しくないので賛否は控えますが、緊急的な荒らし対策なら、非公開で作った後に、詳細は伏せて作成の追認を投げておくのが良いと思います。基準値も試験フィルターを使えば絞れますし。というかそこまでLTAに詳しくフィルターも書けて考えられるなら、権限取得してご自身の能力を活かしていただきたいです。--青子守歌（会話/履歴） 2020年7月26日 (日) 03:21 (UTC)
取り下げ 最近見なくなったので。--Q8j（会話） 2020年11月27日 (金) 17:09 (UTC)
基本多言語面外の文字を含むページ名
提案中
| 目的 | ページ名にUnicodeの基本多言語面(BMP)にない文字を含む場合は常に他のページへのリダイレクトとし、ページ内で追跡用テンプレートを使用するよう利用者に強制する |
|---|---|
| 理由 | Wikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けてでの事前提案によるものです。フィルターの作成を提案したのは私ですが、以下の発動条件はネイさんの2020年5月9日 (土) 05:19 (UTC)の発言から引用しています。追跡用テンプレートというのはTemplate:Title with non-BMPを指しています。 |
| 発動条件 | 「ページ編集（作成を含む）の場合」かつ「ページ名にBMP範囲外の文字を含む場合」かつ（「リダイレクトでない場合」または「リダイレクトであり、追跡用テンプレートがない場合」または「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」） |
| 対処操作 | 警告・不許可 |
-- 本日晴天（会話） 2020年5月29日 (金) 11:23 (UTC)
- コメント 発動条件のうち、「ページ名にBMP範囲外の文字を含む場合」と「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」のところは正規表現を使わないと実現不可能と思われます。個人的には「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」については作品名や組織名などでわずかながらリダイレクトとしての需要があるのではないかと考えており、この部分の判定が特に複雑かつ高コストとであるから、条件から外した方がいいのではないかという気がします。あと利用者名前空間および利用者‐会話名前空間のページと、リダイレクトページの冒頭に即時削除タグを貼るといった編集については発動から除外する必要がありそうです。--本日晴天（会話） 2020年5月29日 (金) 11:23 (UTC)
- コメント 特別:不正利用フィルター/14やUnicodeのEmojiの一覧を参考にして発動条件のコードを作ってみたので、以下に提示します。長いので折りたたんでいます。間違いがあったらご指摘ください。--本日晴天（会話） 2020年6月7日 (日) 08:49 (UTC) コードを1か所修正。--本日晴天（会話） 2020年6月8日 (月) 11:24 (UTC)
発動条件のコード
/* 編集操作 */
( action === "edit" )
/* 利用者名前空間でも利用者‐会話名前空間でもない */
& ( ( page_namespace !== 2 ) & ( page_namespace !== 3 ) )
/* ページ名に基本多言語面にない文字を含む */
& ( page_title rlike "[\u10000-\u10ffff]" )
/* ページの冒頭に即時削除タグがない */
& !( rmwhitespace( lcase( new_wikitext ) ) rlike "^{{(template:)?(sd2?|即時削除2?(/[]+)?|delete)(}}|\|)" )
& (
/* リダイレクトでない */
( isRedirect := ( rmwhitespace( lcase( new_wikitext ) ) rlike "^\#(redirect|転送|リダイレクト):?\[\[.+?\]\]" );
!isRedirect )
/* リダイレクトであるが追跡用テンプレートがない */
| (
( isRedirect )
& !( rmwhitespace( lcase( new_wikitext ) ) rlike "{{(template:)?title_?with_?non-bmp}}" )
)
/* リダイレクトで、ページ名が2文字以上、かつemoji入り */
| (
( isRedirect )
& ( length(page_title) >= 2 )
& ( page_title rlike "[\u1f004" +
"\u1f0cf" +
"\u1f170" +
"\u1f171" +
"\u1f17e" +
"\u1f17f" +
"\u1f18e" +
"\u1f191-\u1f19a" +
"\u1f1e6-\u1f1ff" +
"\u1f201" +
"\u1f202" +
"\u1f21a" +
"\u1f22f" +
"\u1f232-\u1f23a" +
"\u1f250" +
"\u1f251" +
"\u1f300-\u1f321" +
"\u1f324-\u1f393" +
"\u1f396" +
"\u1f397" +
"\u1f399-\u1f39b" +
"\u1f39e-\u1f3f0" +
"\u1f3f3-\u1f3f5" +
"\u1f3f7-\u1f4fd" +
"\u1f4ff-\u1f53d" +
"\u1f549-\u1f54e" +
"\u1f550-\u1f567" +
"\u1f56f" +
"\u1f570" +
"\u1f573-\u1f57a" +
"\u1f587" +
"\u1f58a-\u1f58d" +
"\u1f590" +
"\u1f595" +
"\u1f596" +
"\u1f5a4" +
"\u1f5a5" +
"\u1f5a8" +
"\u1f5b1" +
"\u1f5b2" +
"\u1f5bc" +
"\u1f5c2-\u1f5c4" +
"\u1f5d1-\u1f5d3" +
"\u1f5dc-\u1f5de" +
"\u1f5e1" +
"\u1f5e3" +
"\u1f5e8" +
"\u1f5ef" +
"\u1f5f3" +
"\u1f5fa-\u1f64f" +
"\u1f680-\u1f6c5" +
"\u1f6cb-\u1f6d2" +
"\u1f6d5" +
"\u1f6e0-\u1f6e5" +
"\u1f6e9" +
"\u1f6eb" +
"\u1f6ec" +
"\u1f6f0" +
"\u1f6f3-\u1f6fa" +
"\u1f7e0-\u1f7eb" +
"\u1f90d-\u1f91e" +
"\u1f920-\u1f927" +
"\u1f930" +
"\u1f933-\u1f93a" +
"\u1f93c-\u1f945" +
"\u1f947-\u1f94b" +
"\u1f950-\u1f971" +
"\u1f973-\u1f976" +
"\u1f97a-\u1f9a2" +
"\u1f9a5-\u1f9aa" +
"\u1f9c0" +
"\u1f9ae-\u1f9ca" +
"\u1f9cd-\u1f9fe" +
"\u1fa70-\u1fa73" +
"\u1fa78-\u1fa7a" +
"\u1fa80-\u1fa82" +
"\u1fa90-\u1fa95]" )
)
)
別案1
上で示した発動条件は複雑なので、別の案として「ページの編集操作である（作成を含む）」かつ「利用者名前空間でも利用者‐会話名前空間でもない」かつ「ページ名にBMP範囲外の文字を含む」かつ「{{Title with non-BMP}}を使用していない」という発動条件を提案します。要はページ名にBMP範囲外の文字を含む場合に追跡用テンプレートの使用のみを強制するということです。コードは以下のようになり、当初の案と比べてかなり簡単になります。
/* 編集操作 */
( action === "edit" )
/* 利用者名前空間でも利用者‐会話名前空間でもない */
& ( ( page_namespace !== 2 ) & ( page_namespace !== 3 ) )
/* ページ名に基本多言語面にない文字を含む */
& ( page_title rlike "[\u10000-\u10ffff]" )
/* 追跡用テンプレートがない */
& ( rmwhitespace( lcase( new_wikitext ) ) rlike "{{(template:)?title_?with_?non-bmp}}" )
この案ですとリダイレクトでない状態で作成したり、リダイレクトを解除するような編集は許可するということになります。そのような編集を行うと{{Title with non-BMP}}が（Category:Unicode基本多言語面外の文字を含むリダイレクトではなく）Category:Unicode基本多言語面外の文字を含むページ名を付与する仕組みになっているため、ウォッチリストを活用すれば追跡は容易です。--本日晴天（会話） 2020年6月7日 (日) 08:49 (UTC) 下線部を追記。--本日晴天（会話） 2020年6月7日 (日) 09:14 (UTC) コードを1か所修正。--本日晴天（会話） 2020年6月8日 (月) 11:24 (UTC)
移動荒らし防止フィルター
LTA:SZMYがおとなしくなったと思ったら次はLTA:3SBか、まったく・・・
下記２つ提案します。
フィルターA
不作成
| 目的 | 省略（下記記載） |
|---|---|
| 理由 | 省略（下記記載） |
| 発動条件 | 投稿回数100回未満の利用者が、1時間以内に5回以上ページ移動を行った時（20200806修正） |
| コード | action == 'move' & user_editcount < 100 （と60分以内に5回以上） |
| 対処操作 | 不許可 |
フィルターB
不作成
| 目的 | 省略（下記記載） |
|---|---|
| 理由 | 省略（下記記載） |
| 発動条件 | 投稿回数100回未満の利用者が、
|
| コード | user_editcount < 100 & ( ( action=='edit' & page_age < 600 & old_size < 309 & contains_any ( old_wikitext , '#転送' ) ) | ( action == 'move' & moved_from_age < 300 ) ) |
| 対処操作 | 不許可 |
この提案は複数回変更されています。履歴を表示するには「表示」を押してください
- この提案フィルターの前身
- 2020/02/01 Wikipedia名前空間での移動を防止するフィルター提案→取り下げ（→フィルターA）
- 2020/03/06 他者会話ページの移動を防止するフィルター提案→取り下げ（→フィルターA）
- 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は重い場合があるそうなので）
この２つで移動荒らしを対処可能にすることを目的とします。
１つ目のフィルターにより、1時間以内に行える移動荒らしは3回が限度となり、差し戻しもしやすくなります。２つ目のフィルターは,Wikipedia:編集フィルター/提案/ログ/2020年#移動荒らし対策同様、リダイレクトページをいじられることで差し戻しが一般利用者にできなくなることを防ぐことを目的としています。
いずれも編集回数100回以上の利用者は対象外としています。これは複数のソックパペットが同時に移動荒らしを行った場合、アカウントの数が荒らし＞差し戻し者であった場合、差し戻しをこのフィルターが邪魔することになりかねないとの判断です（50回とするのも考えたんですが、極稀に「荒らしてるうちに編集回数が50回を超える」荒らしがいるので）
２つ目のフィルターについて、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と思われる移動荒らしが２体出現したこともあり、可能ならフィルター作成をおねがいしたいです。--Q8j（会話） 2020年7月18日 (土) 10:18 (UTC)typo--Q8j（会話） 2020年7月18日 (土) 10:19 (UTC)取り消し。一旦--Q8j（会話） 2020年8月6日 (木) 12:36 (UTC)
- コメント コードを書いてみて気付いたんですが、何個か訂正しました。
- 一つ目。1個目のフィルターの発動条件回数を変更しました。5回以上で発動としています。理由として、多分、ですが「ノートページも移動」にチェックした場合、移動が2回カウントされてしまうと思います。そうなると1時間以内の移動を3回まで、としてしまうとノートも同時移動とすると事実上1回までしか移動できなくなってしまいます。なので２倍にしたいところですが、逆に6回まで許可、とすると荒らしがノートを移動しなかった場合や、ノートが存在しないページへの移動荒らしだった場合6回まで移動荒らしができてしまう。これはさすがにあまりよろしく無いだろう、と思い、それの中間という感じで4回まで許可（5回目以降は不許可）としました。つまりノートも同時移動した場合であっても2回までは移動可能です（編集回数を満たす人は当然影響されません）。
- 2つ目。2個目のフィルター、つまりリダイレクトを編集されて一般利用者に差し戻しができなくなる事態を防止するフィルターですが、「移動する時のウィキテキスト」が取得できなさそうです（てっきりできると思ってたんですが）。ので、苦肉の策ですが「作成後5分以内は（リダイレクトかそうでないかにかかわらず）移動できない」としました（user_editcount＝編集回数は使えるので100回以上の利用者は移動は可能です）。新規利用者が作ったばかりのページを移動したくなった場合（WP:NC違反に気づいた時など）は案内文を表示して5分待ってから移動してください、というようにしたいと思います。なお、編集の際はold_wikitextが使えますので、編集の際は当初提案通り「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」となります。
- 以上です。賛成票を投じていただいたTmvさん、この変更後でも賛成していただけますか。他の皆さんはいかがでしょう。大幅に条件を変えたので、意見募集期間を振り出しに戻し、追加1週間（最低）とします。また、old_wikitextなど負荷が高いものを使っていますので、負荷軽減のためにいい案がある方は教えていただけると助かります。--Q8j（会話） 2020年8月6日 (木) 12:36 (UTC)
- コメント 通知が来たので回答いたします. 回数の変更についてですが, 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)
- 変更箇所。「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」の部分のコードに太字部分を加えました。
- 取り下げ 作成/却下の判断や他のコメントがなされないまま3ヶ月経過してしまったので取り下げます。--Q8j（会話） 2020年11月27日 (金) 17:08 (UTC)
意図の分からない重大編集の抑制
提案中
| 目的 | 意図の分からない重大編集の抑制 |
|---|---|
| 理由 | 「記事への重大（大胆）な編集」について、要約欄の記入を必須とすることで、意図を明確にさせるため |
| 発動条件 | 「記事への重大（大胆）な編集」（詳細は下を参照）が行われようとしていて、かつ要約欄が空 (summary == "") である時
|
| 対処操作 | 警告・不許可 |
「記事への重大（大胆）な編集」として次を想定しています。
- 記事の分量を一定程度（詳細については議論しましょう）減少させる編集
- Wikipedia:ウィキペディアについてでは、「ウィキペディアは、信頼されるフリーなオンライン百科事典、それも質・量ともに史上最大の百科事典を、共同作業で創り上げることを目的とするプロジェクト」とかかれており、記事の分量を減少させる編集については、「質・量ともに史上最大の百科事典を、共同作業で創り上げる」という観点からは逆行するように思えるため。もちろん、冗長な箇所を削除したり、Wikipedia:ウィキペディアは何ではないか#ウィキペディアは情報を無差別に収集する場ではありませんに抵触する部分を削除したり、法的な問題が惹起される編集を指し戻す場合もありますが、このような場合は要約が提供されてしかるべきです。
- Category:存命人物にカテゴライズされている記事に対して、「逮捕」「麻薬」「覚せい/（醒）剤」「MDMA」「不倫」などのネガティブワードを追加する編集
- Wikipedia:存命人物の伝記・Wikipedia:削除の方針#ケース B-2:プライバシー問題に関してに提唱する可能性のある編集であるため。
- Infobox系テンプレートの「名前」「name」「愛称」「nickname」「正式名称」「official name」系パタメーターの引数を変更する編集
これも「記事への重大（大胆）な編集」にあたるのではないか、あるいは上の編集の内これは「記事への重大（大胆）な編集」ではないという意見も含めて、意見を賜りたいです。 片割れ靴下（会話） 2020年5月20日 (水) 17:57 (UTC)
- 3番目を追加しました。 片割れ靴下（会話） 2020年5月20日 (水) 18:05 (UTC)
- 質問 このフィルターの目的は、「荒らしをこれによって防ぐ」ことでしょうか？それとも要約欄に書かない初心者や書き忘れた人に案内することでしょうか？--Q8j（会話） 2020年6月1日 (月) 12:28 (UTC)
- 色々です。例えば金田一少年の事件簿 (アニメ)でのある編集は、編集者がなぜこうした「おまじない」が存在するのか理解しないで削っているのか、この「おまじない」が折りたたみや2列での表示のためだとわかっていて、削ろうとしているのかという説明が提供されれば、差し戻すべきか差し戻さないべきかという判断を下しやすくなります。プライメイトシティでのある編集は、ビジュアルエディターを使わずに大規模な票を編集してしまったために、レイアウトが大きく崩れてしまっています。通常、こうした編集への対応は差し戻しが主流ですが、この人がこの編集でしたかったことを要約欄で教えてくれれば、単なる差し戻しではなく、この人の意向をくんだ表組みの修正という選択肢も出てきます。また、要約欄を書かないと荒らせないようにすることで荒らしの速度を少しでも低下させたり、手間を掛けさせることができると思います。 片割れ靴下（会話） 2020年6月1日 (月) 13:12 (UTC)
半保護突破のための編集数稼ぎ防止
提案中
| 目的 | 半保護突破のための編集数稼ぎ防止 |
|---|---|
| 理由 | 同上 |
| 発動条件 | 編集回数500回を満たさないユーザーが ・自らの利用者ページ、利用者ノート、利用者サンドボックスを少ないバイト増減（100バイト未満、随時見直し）で、複数回編集を繰り返す ・ある特定ページを複数回、少ないバイト増減（100バイト未満、随時見直し）で、複数回編集を繰り返す |
| 対処操作 | 不許可 |
LTA:ASPEやLTA:203、LTA:Iccicなどで、半保護突破を目的とした編集数稼ぎが多く発生しています。実現可能なものから早期に実装し、必要に応じて随時拡張をお願いしたいと思います。--Taisyo（会話） 2020年2月2日 (日) 03:46 (UTC)
- コメント 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. また、「自動承認された利用者」になる以前の段階で取消しになった場合はどうなるのでしょうか。やはり５日間は何をしても「自動承認された利用者」にならないのでしょうか。
- 返信 その認識で合っています。
- A-1. これは、すでに自動承認されていても取り消されて新規利用者とされる、ということですね。「取り消しから5日間承認されない仕様」ということは、その５日間はどんなに多くの編集をしても「自動承認された利用者」にならない、ということでしょうか。
- A「自動承認ステータスを取り消す」：
- B.「X秒内にY回以上フィルターにひっかかる操作を行った場合のみ発動」：
- B-1. これは同じページの編集に対してのみ発動するのですね。同一の利用者が投稿先を次々と変えて編集した場合は、「X秒内にY回以上」の編集をしても発動しないのですね。（というよりそういう条件は検出はできないかもしませんが）
- 返信 「X秒内にY回以上」は正確には「フィルターの発動条件にひっかかる編集をX秒内にY回以上」なので、フィルターの発動条件によります。たとえば、Wikipedia:サンドボックスでの編集のみ検出するという条件の場合、投稿先を変えることでフィルターにひっかからなくなり、回避できます。条件のほうで調整することになります。
- B-2. 必然的に、あるページの編集に対してフィルターが発動してしばらく投稿できない状態になったとしても、別のページでは普通に投稿できるのですね。
- 返信 フィルターの発動条件にひっかからない編集であればできます。たとえば、バイト数変動が+100未満の場合のみ検出する場合、バイト数変動を+100以上にすることで投稿できるようになります。
- B-1. これは同じページの編集に対してのみ発動するのですね。同一の利用者が投稿先を次々と変えて編集した場合は、「X秒内にY回以上」の編集をしても発動しないのですね。（というよりそういう条件は検出はできないかもしませんが）
- B.「X秒内にY回以上フィルターにひっかかる操作を行った場合のみ発動」：
- C.フィルター発動後に投稿再開できる条件：「「X秒内にY回以上」を満たさなくなるまで投稿できません」どうもよくわからないし、これが肝心なところですので具体的な数値例で詳しく伺いたいと思います。仮に「60秒内に10回以上」の投稿で発動する設定とします。
- C-1. この場合、フィルターが発動してから何秒経過したら次の投稿が出来るようになるのでしょうか。早ければ数秒以内、最長でも60秒経過すれば次の投稿ができるのでしょうか。
- 返信 最長でも60秒経過すればできます。
- C-2. また、この条件にさらにバイト数の制約を入れ「60秒内に100バイト未満の編集を10回以上」とした場合はどうでしょうか。この場合は、フィルター発動直後でも100バイト以上であれば投稿できるのでしょうか。
- 返信 その認識で合っています。（B-1、B-2への回答も参照）半保護されたページの場合は自動承認が取り消されているため投稿できません。
- C-1. この場合、フィルターが発動してから何秒経過したら次の投稿が出来るようになるのでしょうか。早ければ数秒以内、最長でも60秒経過すれば次の投稿ができるのでしょうか。
- C.フィルター発動後に投稿再開できる条件：「「X秒内にY回以上」を満たさなくなるまで投稿できません」どうもよくわからないし、これが肝心なところですので具体的な数値例で詳しく伺いたいと思います。仮に「60秒内に10回以上」の投稿で発動する設定とします。
- いろいろと御手数おかけしますが、よろしくお願いします。--Loasa（会話） 2020年4月29日 (水) 07:02 (UTC)
- 追加質問です。
- A-5. 取り消されてから５日の間に再びフィルターの発動条件に引っ掛った場合、自動承認されない期間はその分延長されるのでしょうか。たとえば、最初に取り消されてから４日目に再びフィルターに発動された場合、最初に取り消されてから9日後まで承認されないということでしょうか。
- 返信 対処操作が発動するごとに自動承認できるまでの期間が5日にリセットされるので、最後の発動から数えて5日間自動承認されないことになります。
- A-5. 取り消されてから５日の間に再びフィルターの発動条件に引っ掛った場合、自動承認されない期間はその分延長されるのでしょうか。たとえば、最初に取り消されてから４日目に再びフィルターに発動された場合、最初に取り消されてから9日後まで承認されないということでしょうか。
- --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回以上の編集にカウントされない）」という設定はできるのでしょうか。
- B.「フィルターの発動条件によります。」「条件のほうで調整することになります。」というのがよくわかりません。
- --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相手には）無駄なフィルターになる可能性はあると思います（もちろんバイト数を増やすことで多少は対応できるでしょうが、こっちが２倍にするだけで巻き添えを考慮しないといけないのに対し、あちらはコピペ一回で済むわけで、いたちごっこはこっちが圧倒的に不利です）。というわけで効果は疑問（正確にはいつまで保つか疑問）ですが、まぁ効かなくなったら残念でした、で無効化すればいいですし、一時的でも効けばその一時は効果がある。希望的観測ですが、悟られなければずっとLTAの邪魔ができるかもしれない。というわけで、色々書きましたが概ね賛成です。
- 仕様について、Loasaさんの案に少し考えてみました。
- F2。500回、とおっしゃいますが、このフィルターの目的は半保護突破防止のはずです。自動承認されていないが、IPでもない、で十分では？（投稿回数が10回を超えたら、その後の編集は「半保護突破目的」ではなくなりますし、拡張半保護突破は到底現実的ではない）。必要ない利用者の編集を検出することは負荷、誤作動につながります。
- F3、対象ページ。私はすべてのページではなく、「標準名前空間以外」でいいような気がするんですが、どうでしょうか。現時点203がターゲットに使うのはサンドボックスが圧倒的に多いという印象ですが、LTA:ASPEやLTA: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の後半で述べたことがすべてですが、もう少し演説します。フィルタに限らずこの種の防御システムは、その効用や緊急性・重大性と副作用のバランスで考えるべきです。たとえば、その防御システムが対象とする問題行為が、ウィキペディアに対して致命的といえるほど重大な損害を与えるようなものであり（重大性）、かつ、緊急な対策を要するものでもあり（緊急性）、かつ、その防御システムがその行為に対する阻止として有効に働く(効用）ものであるならば、若干の副作用はやむを得ないでしょう。しかし本フィルタの対象とする問題行為は、そこまでしなければならないほど緊急性や重大性の高いものではありません。有効性という点でも（パラメーターを非公開にしたとしても）上でコメントされているようにいずれは突破されてしまうだろうし、多少時間をかければフィルターの意味もなさなくなる可能性が高いものです。本フィルタの効果はその程度しか期待できないのに対して、無関係な初心者が引っかかる確率がほぼ１００％であり、しかも短時間とはいえ、ブロックの可能性もあるというリスクは効果に見合ったものとはいえません。そして、フィルタの仕様上、非常に高い確率で無関係な初心者が引っかかる可能性は避けられません。ならばせめて副作用が発生したときの救済措置を十二分に用意しておく必要があります。私の考えではその救済措置の一つがパラメーターの閾値公開なのです。初心者が引っかかったときにT時間待てば自動的に回復できる、とわかるだけでも安心できます。たとえ短時間でもそれがわからないのは非常な不安になるものです。
- そのようなわけで、細かい仕様はお任せしてもよいのですが、パラメーターの閾値公開だけは絶対的な条件とします。ただ、多少は妥協して、NやBに関しては非公開でもよいでしょう。公開するのは最大ブロック可能時間、すなわちTの最大値だけでもよいとします。Tの最大値の公開すら駄目ということであれば、このフィルタは有用性のわりに副作用の害が大きすぎるということで、フィルタの作成自体に反対とさせていただきます。パラメーターTの最大値の公開すら認められない、ということであれば、それならばこのフィルタを作るのは止めましょう、というのが私の最終的な結論です。--Loasa（会話） 2020年12月31日 (木) 07:18 (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)
- 議論が半年以上停止しているため、これ以上コメントがなければ、1週間後に賛成票なしとしてクローズします。--ネイ（会話） 2020年12月29日 (火) 05:22 (UTC)
脚注がない記事の作成
提案中
| 目的 | 正しく働く脚注がない記事を検出する。 |
|---|---|
| 理由 | 出典を示すときは出典節に列挙するのではなく脚注を使って文章がどの出典に対応するか示す必要がありますが、脚注がない記事ではそれができていないと考えられます。出現率もかなり高く、特別:新しいページから100ページほど調べた結果、出典があるのに{{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)
却下 2年以上賛成票がなく、Check Wikipediaで抽出されているためAWBなどで簡単に修正できるものとして、今回は却下します。--ネイ（会話） 2020年12月29日 (火) 05:19 (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人以上の賛成があり、かつ反対がなかったため合意成立とみなします。ただし、発動条件の詳細についてお聞かせください：
- 過去ログ化は除外しますか。除外する場合、どのような条件を想定していますか。
- 「ノートページで除去があった」の判定条件は何を想定していますか。「removed_linesが空ではない」という条件では緩すぎると考えます。
- 以上です。--ネイ（会話） 2018年1月12日 (金) 14:20 (UTC)
- 返信 過去ログ化のみを抽出するのは難しいと考えているため、過去ログ化を含めて検出することを考えています。当初考えていた判定条件は「removed_linesが空ではない」でしたが単純な追加も検出してしまうので、複数行に書き加える頻度は低いと仮定する必要はありますが「removed_linesが複数行あるか、added_linesが空である」あたりでしょうか。--プログラム（会話） 2018年1月15日 (月) 14:02 (UTC)
- コメント 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系のキーワードや他の機能を使って同様の「キーワード検出」を意図したコードも対象に含まれます。
なぜこんなコードが多く存在してしまっているかというと、おそらく
- 最初に「追加除去キーワード一致」系のフィルターを作った編集者が、編集フィルターの仕様について無知であったためバグを埋め込み
- さらに動作状況について定期的な確認を怠って偽陽性に気づかないまま放置し動作し続けており
- それをまた別に無知なフィルター編集者が中身を理解せずコピペして（＆発動結果の確認が不足して気づかず放置して）
- かついずれもフィルターの作成報告義務を果たさなかったためフィルターの内容周知が不十分で
- 上記2-3が繰り返されねずみ算的にバグコードが増加し
- 最後に止めるべき他のフィルター編集者の相互監視も不足し今日まで誰も指摘しなかった
という悪い連鎖があったのだと思います。 直接的には1-5番のような行動をしたフィルター作成者の責任が重いものの、最後の要因を考えれば、このような低質なフィルターが蔓延してしまったのを許したのは、私を含めたフィルター編集者全員の問題だったと思います。 特に、対処操作を不許可にしているフィルターにおいて偽陽性を埋め込んだ＆長期間放置した＆見過ごしたのは、なによりも避けるべきことであって（cf. ガイドライン）、これによって少なくない数の善意の利用者の意欲を削ぐことでウィキペディア日本語版の発展を大きく阻害してしまったことを自覚しましょう。
そこで、ここでは現時点で編集フィルターの編集権限を持っている全員に上記内容を通知し、以降に同様の問題を再発させないよう徹底させると共に、現時点で存在する（有効化されている）フィルターの全再点検＆修正を始めたいと思います。
まず以下、フィルター編集者全員への通知＆確認です（順は就任日順）。上記内容を全て読んで理解した方は、後ろに自分の4チルダ署名を書いてください。気になる点・不明点・コメントなどあれば本節末尾で解決してから署名をお願いします。 3ヶ月程度経過しても署名されていない場合は、フィルター編集者として活動する予定がないか、理解できる＝フィルターを正しく設定するだけの能力が不足していると考えられるので、フィルター編集権限の除去依頼を出すことを先に予告しておきます。 また、追加作業や手戻りを避ける観点から、上記内容を理解するまで（署名するまで）、各位にはフィルターの新規作成を含むフィルターの編集は控えていただくようお願いします。
- @Ks aka 98:
- @青子守歌:--青子守歌（会話/履歴） 2020年12月26日 (土) 02:53 (UTC)
- @Muyo:
- @Penn Station:
- @Chatama:
- @Triglav:
- @Iwai.masaharu:
- @Jkr2255:
- @VZP10224:
- @Taisyo:--Taisyo（会話） 2020年12月26日 (土) 12:30 (UTC)
- @Ohgi:
- @Tomo suzuki:
- @Cpro:
- @Whym:
- @Freetrashbox:
- @MaximusM4:
- @Y-dash:--Y-dash 2020年12月26日 (土) 22:27 (UTC)
- @ネイ:--ネイ（会話） 2020年12月28日 (月) 12:36 (UTC)
- @赤の旋律:
- @Infinite0694:
- @アルトクール:
- @Yapparina:
- @えのきだたもつ:
- @Miya:
- @Sumaru:
- @伊佐坂安物:
- @Sakoppi: --Sakoppi (会話・投稿記録) 2020年12月26日 (土) 03:32 (UTC)
- @W.CC:--W.CC（会話） 2020年12月28日 (月) 10:27 (UTC)
次に現時点で存在しているフィルターの確認＆修正ですが、数がかなりあるので人海戦術するしかなく、上記で理解した署名をつけられたフィルター編集権限を持っている全員で、時間のある限り少しづつ協力をして、進めましょう。 以下の表に、少なくとも(added|removed)_linesが含まれる現在有効なフィルターの一覧を書いておきました（検索機能で抽出した）ので、これを全部埋めれば完了で良いと思います。
各セルに
- 修正の要・不要確認（不要な例：キーワード系ではない/意図して行単位条件になっている、など。先述の通り、例であげたコードそのままだけではなく同様の機能を使ったコード全てが修正が必要な対象です）
- 修正の完了報告（{{編集フィルター履歴}}をつけて）
をそれぞれ署名付きでお願いします。 どちらかだけでも、両方ともでも構いませんが、判断に迷う場合、フィルター作成者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)
- @Freetrashbox: 模範例は既に冒頭に書いた通り(added|removed)_linesを両方確認する以上はないのですけれども、具体例をということでフィルター#17の第2423版（差分）を修正しました。例えば、要不要コメントにある特別:不正利用記録/1327626はこれで条件一致しなくなりますが、（意図が正しいかはおいといて）意図通りと考えられる特別:不正利用記録/1306000はこれまで通り条件一致します（それぞれに対して#17を試験すれば確認できます）。--青子守歌（会話/履歴） 2020年12月30日 (水) 03:21 (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)
- 私向けのメッセージがあったので。確かに「実際に使っているかどうか」「実際に有効性があるかどうか」のコメントです。修正の必要・不要では見ていないです。元の構文（今回は禁句系フィルターの元）を作るのは正直に難しいです。半面、引っ掛けるワードを考えるのは、結構有効なワードを見つけています。あとのコメントにもつながるのですが、構文が分からない人でも「本文ｏｒ概要、両方か」、「反応させる編集数」・「引っ掛けたいワード」を入れたら簡単に動く「禁句系フィルター」を用意した方が良いのではと思います（できたとして、移行をどうするかの問題はありますが）。--Taisyo（会話） 2020年12月26日 (土) 13:02 (UTC)
- @Miya and Taisyo: 表の下の「こういう風に書いてください」というお願いにちゃんと書いてある通り、また、本日の晴天さんや私の前例通り、その列では修正の要・不要を求めています。なぜならここは「フィルターを修正する必要がある」という変更提案の場であって、フィルターを廃止するという話は別にしていませんので（廃止しても良いから修正不要、という話ならそれはそれで良いと思いますが）。というわけで、もし間違った意味で書いてしまっていたのなら、修正あるいは除去してもらえますか。表の方にも間違えないように明記しました。--青子守歌（会話/履歴） 2020年12月26日 (土) 13:19 (UTC)
- 了解しました。削除時の偽陽性反応問題の対応で、構文問題であることを理解しました。そのあと、この様な目線でのコメントに書き換えます。だた、偽陽性判定も問題ではありますが、いくつか見ていて他の問題点も見つけました。
- 現在使用していない（極端な話削除済も）の同様のフィルターも、コピペによる拡散防止のために正しい公文に書き換えるべきでは。
- 数が多いのは仕方ないにしても、同じ目的のフィルターが複数ある場合があるので、まとめた上で廃止フィルターを削除するべきでは。
- 削除時の偽陽性を含め、他に考えられる対応を行った方が、さらに良いのではと思います。--Taisyo（会話） 2020年12月27日 (日) 05:19 (UTC)
- 了解しました。削除時の偽陽性反応問題の対応で、構文問題であることを理解しました。そのあと、この様な目線でのコメントに書き換えます。だた、偽陽性判定も問題ではありますが、いくつか見ていて他の問題点も見つけました。
- @Miya and Taisyo: 表の下の「こういう風に書いてください」というお願いにちゃんと書いてある通り、また、本日の晴天さんや私の前例通り、その列では修正の要・不要を求めています。なぜならここは「フィルターを修正する必要がある」という変更提案の場であって、フィルターを廃止するという話は別にしていませんので（廃止しても良いから修正不要、という話ならそれはそれで良いと思いますが）。というわけで、もし間違った意味で書いてしまっていたのなら、修正あるいは除去してもらえますか。表の方にも間違えないように明記しました。--青子守歌（会話/履歴） 2020年12月26日 (土) 13:19 (UTC)
- 私向けのメッセージがあったので。確かに「実際に使っているかどうか」「実際に有効性があるかどうか」のコメントです。修正の必要・不要では見ていないです。元の構文（今回は禁句系フィルターの元）を作るのは正直に難しいです。半面、引っ掛けるワードを考えるのは、結構有効なワードを見つけています。あとのコメントにもつながるのですが、構文が分からない人でも「本文ｏｒ概要、両方か」、「反応させる編集数」・「引っ掛けたいワード」を入れたら簡単に動く「禁句系フィルター」を用意した方が良いのではと思います（できたとして、移行をどうするかの問題はありますが）。--Taisyo（会話） 2020年12月26日 (土) 13:02 (UTC)
- @Miya: rmwhitespaceやlcaseは引数の文字列を置換するだけの関数なので、問題があることに変わりありません。投稿者が追加除去していないキーワードが含まれているのは同じですので。--青子守歌（会話/履歴） 2020年12月28日 (月) 01:14 (UTC)
コメント 禁句系フィルターは上手に使えば、記事の保護やIPのブロック数など減らすことが出来るなど有効な側面もあります。また、個人名をばらまく、いわゆる「知能知数が低いと思われる事が原因のLTA」には相当有効（そうしないと抑止力が無い）です。構文ミスを防ぐ側面もあり、2015年7月17日のフィルター37の不具合時に「簡単に運用できる禁句系フィルター機能」の実装をお願いした記憶があります。しかし、「メタに要望しています」や「お願いしましたが出来ませんでした」など、連絡はいただけておりません。今でも、「簡単に運用できる禁句系フィルター」の実装をお願いしておりますので、今からでも良いので、動いてもらえないでしょうか。実際の動作状況は、フィルター37の不具合以降は、目に見える形での大規模不具合は起こしていないはずです。--Taisyo（会話） 2020年12月26日 (土) 12:54 (UTC)
- 優先して修正すべきなのは投稿が差し止められる（かつ無効化されていない）フィルターあたりでしょうか。対処操作が何も付いてないフィルターは当面放置しても実害はほぼないだろうと思います。[1]から「対処操作」の列をコピーしておきました（ただし、あくまで現時点の対処操作を記しているだけなので、今後フィルターが変更されれば齟齬が出るかもしれません）。 --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)
- 【署名について】「理解した方は署名を書いてください」と「理解するまでフィルターの編集は控えてください」を切り分けてほしいです。つまり
- ひとまず、3か月という設定にこだわりがないとのことで安心しました。私もご提案の趣旨や目的には賛成しております。オーバーサイトのお2人に対する除去反対を除けば、「そこまで目くじら立てて「やりすぎ」と主張する」ほどのことをしたつもりはないのですが、そのように伝わってしまったのであれば申し訳なく思います。幅広く活動していらっしゃる青子守歌さんにおかれましては十分ご存じのことと思いますが、強い言葉を使えば強い反応が返ってくることは自然なことですので、表現にはご配慮いただければと思います。--W.CC（会話） 2020年12月28日 (月) 14:55 (UTC)
CSSページで#57が発動しないようにする提案
TemplateStyleを利用する目的でTemplate:メインページ/test.cssを作成しようとしたところ、編集フィルター#57（変更履歴・一致記録）が発動しました。<!-- [[Category:○○○]] -->を記入することでカテゴリを付与することも一応可能ですが、基本的にCSSページにカテゴリは不要と考えます。つきましては、#57の発動条件に「.cssで終わるページ名でない」を追加することを提案します。--本日晴天（会話） 2020年6月24日 (水) 03:51 (UTC)
- 取り下げ Category:テンプレートスタイルというカテゴリが存在することを後になって知りました。こちらの提案は取り下げます。--本日晴天（会話） 2020年12月24日 (木) 07:38 (UTC)
- 却下 クローズします。--ネイ（会話） 2020年12月29日 (火) 04:52 (UTC)
利用者ページの移動に対して編集許可できなくなった
Wikipedia‐ノート:編集フィルター#新規アカウントによる他者利用者ページの移動の条件についての対応をしていて気づいたのですが、（おそらく編集フィルター本体の機能の変更によって）移動操作の時に元のウィキテキストが取得できなくなっていました。つまり、編集フィルター#12（変更履歴・一致記録）で移動の時に、{{編集許可}}があるか判別できず、編集許可（この場合は移動許可）ができなくなりました。
代替方法がないので、完全に偽陽性を排除するためには、諦めて移動を防ぐのはやめる（移動は自由にする）しかないのですが、昨今の荒らし状況などから考えてもあまり有効ではないと思います。
ということで、仕様を変更（明記？）し、移動には編集許可は使えないようにしました。「新規利用者でも自由に移動してもらいたいような利用者ページは普通はないだろう」（編集ならともかく）という想定です。{{編集許可}}の説明文にも書いておきました。
以上、追認依頼を兼ねて記録しておきます。「実はこれなら解決できるよ！」という良い方法を見つけられた方は、修正いただけると助かります。--青子守歌（会話/履歴） 2020年3月8日 (日) 03:35 (UTC)
- @青子守歌: 代替方法はなく、苦肉の策なんですが「strpos(moved_from_recent_contributors,user_name) == 0」とかどうでしょう。僕の理解が正しければ、移動するページ（この場合利用者ページ）の最後の編集者が移動者と同じであればtrueになる・・・と思うんですが。{{編集許可}}使って、移動する人はそのページをテキトーに1回編集する。そしたらmoved_from_recent_contributorsの最初が編集者（＝移動者）になり、移動できる・・・はずです。まあ抜け道はできちゃうんですが・・・--Q8j（会話） 2020年7月28日 (火) 02:32 (UTC)
- 今さらですが、仕様変更の追認に賛成します。グローバル利用者名変更者については別の提案で扱います。利用者サブページならば移動してもらいたいページはありそうですが、抜け道を用意する程でもないと思います。--ネイ（会話） 2020年12月29日 (火) 05:33 (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)
- 賛成 追認に賛成します。
{{AlLoWeDiT}}のようなケースも許可しますが、それも意図的なものとして扱っていいでしょう。--ネイ（会話） 2020年12月29日 (火) 05:35 (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)
#12でグローバル利用者名変更者に関する条件を外す提案
編集フィルター#12（変更履歴・一致記録）（新規利用者による他利用者ページの編集）はグローバル利用者名変更者による編集を除外する必要がありました。しかし、利用者名変更操作に伴うページ移動はphab:T212082での修正（2019年9月）により編集フィルターにかからなくなったため、除外の必要がなくなりました。したがって、当該条件の除去を提案します。--ネイ（会話） 2020年12月29日 (火) 05:45 (UTC)
ログ
- Wikipedia:編集フィルター/一覧 - 正式運用中のフィルターの一覧と議論の過去ログ
- Wikipedia:編集フィルター/提案/ログ - 正式運用に至らなかったフィルターの議論の過去ログ