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

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

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

提案と作成

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

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

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

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

新しく提案するには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログ化

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

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

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

提案中のフィルター

連投対策

提案中

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

詳しくは利用者‐会話: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権限保有者は以下の通りです。
    • jawpローカル・・・アカウント作成者、ボット、ビューロクラット、削除者、スチュワード（ローカルは0人です）、管理者
    • グローバル・・・Jimbo Wales's group、Global bots、Global rollbackers、Global sysops、New wikis importers、Staff、Stewards
  • この方法であれば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)

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

提案中

目的	ページ名に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回未満の利用者が、 リダイレクトページであり、かつ、ページ作成から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は重い場合があるそうなので）

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

１つ目のフィルターにより、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)

---

• 取り下げ 作成/却下の判断や他のコメントがなされないまま3ヶ月経過してしまったので取り下げます。--Q8j（会話） 2020年11月27日 (金) 17:08 (UTC)

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

提案中

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

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

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

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

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

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

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

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

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

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

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

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

提案中

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 追加質問です。

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

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

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

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

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

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

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

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

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

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

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

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

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

F2.対象となる利用者：

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

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

F3. 対象となるページ：

すべてのページ

F4. 発動条件：

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

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

F5.発動時の対処：

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

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

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

解説：

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

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

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

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

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

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

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

@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)

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

提案中

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

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

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

脚注がない記事の作成

提案中

目的

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

理由

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

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

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

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

提案中

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

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

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

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

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

ノートページでの除去

提案中

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

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

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

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

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

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

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

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

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

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

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

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

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

試験中のフィルター

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

作成済

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

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

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

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

作成済

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

仕様変更提案

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

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

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

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

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

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

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

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

AllowEditの正規化

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

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

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

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

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

{{
allowedit}}

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

{
{al
        lowe
 dit}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#2の対処操作

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

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

#2の廃止提案

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

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

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

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

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

#15の対処操作

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

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

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

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

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

#20を公開する提案

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

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

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

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

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

#49の仕様変更について

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

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

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

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

②Wikipedia:記事の所有権

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

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

⑤Wikipedia:即時削除の方針

⑥Template:User Wiki-3

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

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

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

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

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

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

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

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

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

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

提案内容から考えるに、確実にこれを貼っている人なら分かっている、と言えるものに今回は絞りませんか。それで拡張・縮小がいるならまた考えませんか。--遡雨祈胡（会話） 2020年8月6日 (木) 17:00 (UTC)

併せて、Wikipedia:編集フィルター/一覧/利用者ページのルール告知ならびにWikipedia‐ノート:ウィキペディアへようこそ #利用者ページでの個人情報記載に関する注意喚起についてがこのフィルターができた理由であることから、除外するとすれば①だけが適応されるのがいいのではないでしょうか。--遡雨祈胡（会話） 2020年8月6日 (木) 17:21 (UTC)

一つの案では少ないと思い複数案出していましたが、①だけ適応という案に変更します。--210.248.148.149 2020年8月7日 (金) 14:32 (UTC)

すみません、コロコロ意見を変えて申し訳ないですが、自分で書いた文書を読み直していたのですが、そもそも利用者ページへのリンクを貼ったことと、あのテンプレートの中身が表示されたことをイコールで考えるのはなんというか、ずれている気がします。そもそも、テンプレートの内容を読んでいれば「書かないでほしい」という内容ではないことは分かりますし、それで説明が不足するのであれば表示される文面の修正などを考えた方が本来の目的に近いのではないでしょうか。--遡雨祈胡（会話） 2020年8月19日 (水) 16:25 (UTC)

確かに、文面の中身は書かれて困ることはないかもしれません。しかし、編集フィルターはかつて不正利用フィルターと言われて他Wikiでは今でも「不正利用フィルター」「不正利用記録」と言われていますし、それ以前から編集している私としてはフィルターの適用は必要な場合のみにしてほしいと考えています。今でも、予想外に適用されて困惑、面倒に感じるのはあり得ます。このフィルターの意義は分かりますし、初心者で利用者ページの使い方が理解できない方への適用はいいと思っていますが、利用者ページの使い方が理解できている方への適用はどうかな、と私は考えています。--210.248.148.148 2020年8月24日 (月) 09:03 (UTC)

• コメント すみません、本当にどうでもいいことなのですが、MediaWiki:Abusefilter-warning-利用者ページのルール告知にある「ご自身の利用者ページであればWikipedia:即時削除の方針#利用者ページ1が適応できます。」の「適応」はひょっとして「適用」の間違いだったりしませんか？修正ついでに確認いただけると幸いです。--Q8j（会話） 2020年8月19日 (水) 16:31 (UTC)

すみません、それは誤字です。ちゃんと確認しておくべきでした。本当に申し訳ございません。--遡雨祈胡（会話） 2020年8月19日 (水) 16:49 (UTC)

文面の修正は私は思いつきませんでしたが、Q8jさんが指摘された「適応」から「適用」への修正は賛成します。あえてもう一つ言及するなら、
File:Ambox warning orange.svg
のテンプレートの除去提案ですね。驚いてしまいますし、文面だけでも見ると私は考えます。--210.248.148.150 2020年8月25日 (火) 09:52 (UTC)ファイルがそのまま貼られてたのでファイルリンクへ変えました。現状のままだと大きすぎたので。--Q8j（会話） 2020年8月25日 (火) 09:56 (UTC)

個人的には除去ではなくなにか別のものに差し替えるか、残すほうがいいと思います。先日とある初心者の方が「以上の内容を完全に〜」の文面を読まずに投稿されてしまい、削除依頼を提出したと言うのもありますし、フィルターに掛かった方には何で引っかかったか見てわかるようにアイコンを表示することそのものはあったほうがいいと考えます。--遡雨祈胡（会話） 2020年8月29日 (土) 01:33 (UTC)

現時点では合意の取れそうな、誤字の件だけとりあえず対応いただくのでいかがでしょうか。--遡雨祈胡（会話） 2020年9月5日 (土) 14:13 (UTC)

例えばアイコンであれば、File:Calligra Braindump icon.svgなどに差し替えるという手もあると思いますが、いかがでしょうか。--遡雨祈胡（会話） 2020年9月7日 (月) 15:35 (UTC)

提案ありがとうございます。現時点では合意できそうな、誤字の件とFile:Calligra Braindump icon.svgの案に賛成します。合意できそうな案に絞っていただいたところなんですが、別の節で言及したようにフィルターにかかるのをマイナスに捉える人がおり、不便にも感じるのもあり、IPで有意な編集経験があり、利用者ページの意義を理解している場合や副アカウント作成で経験者で利用者ページの意義を理解していて当該フィルターが必要がないケースもあると思うので、私が最初に考えた案①についてもどのような条件ならいいか別途考えていただければ幸いです。--210.248.148.147 2020年9月8日 (火) 11:38 (UTC)

考えるとして、最大の論点は「何をもって」判定するかでしょう。そもそもウィキペディアは原則一人一アカウントです。誤解を招くことを防ぐために別アカウントを作成したりするケースがあるのは存じておりますが、どうやって判定するかをもう少し厳密に判定しないと難しいのではないかと個人的には思います。--遡雨祈胡（会話） 2020年9月8日 (火) 13:26 (UTC)

すみません、当方の理解が足りませんでした。アイコンが変えられません。Template:編集フィルターの警告を参照すると分かりますが、こちらをベースに作っておりますので、画像を差し替えるにはテンプレートそのものから作る必要があります。なお最低限文字を修正すると以下の形になると思われます。

ちなみに画像は「深刻さ」を低にすると変えられますが、これをやってしまうと説明も省略されてしまい（表示にはクリックが必要になる）、それだと過去に発生した個人情報の不用意な掲載が発生する可能性があり、また210.248.148.147さんのおっしゃる「メッセージそのものの非表示」も行われるわけではないので、この案には反対します。--遡雨祈胡（会話） 2020年9月8日 (火) 13:48 (UTC)

了解しました。その部分を訂正して賛成取り下げします。「何をもって」判定するかについては後日言う予定です。--210.248.148.151 2020年9月9日 (水) 14:35 (UTC)

担当者の方にお願いしたいのですが、誤字の部分だけ修正頂いたら本件を終了として頂けますでしょうか。判定に関しては議論が長くなり過ぎてしまったので別の節で改めて実施いただく方がいいと考えております。--遡雨祈胡（会話） 2020年10月27日 (火) 16:39 (UTC)

返事が遅くなりすみません。代案はあるにはあるのですが、別の節で改めて実施した方がいいのなら別の節で続きをしたいと思います。私はMediaWiki:Abusefilter-warning-利用者ページのルール告知の編集をすることができませんので、どなたか提案にあった誤字の編集をしていただければと考えております。--210.248.148.154 2020年11月14日 (土) 13:39 (UTC)

報告 Wikipedia:管理者伝言板/保護ページ編集にて書き換えを依頼しました。--Q8j（会話） 2020年11月15日 (日) 09:39 (UTC)

済 Sakoppiさんにより編集されました（Special:Diff/80453961）。--Q8j（会話） 2020年11月16日 (月) 10:29 (UTC)

#5にPJT:を追加する

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

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

#26の無効化

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

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

ログ

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