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

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

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

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

提案と作成[編集]

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

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

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

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

新しく提案するには[編集]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログ化[編集]

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

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

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

提案中のフィルター[編集]

コメントアウト[編集]

作成済 作成済
目的 コメントアウトしている編集にタグ付け
理由 情報の大幅削減や問題ある記述を含む場合など、監視上重要な編集となることが多いが、RCなどでバイト数の増減では気付けないので

-- Ks aka 98会話) 2014年6月13日 (金) 06:34 (UTC)

User:Ks aka 98さん:編集フィルター#30変更履歴一致記録 のような感じでしょうか(23日以前の致記録は無視してください)。 --whym会話) 2014年6月25日 (水) 10:01 (UTC)
こんな感じです!!/編集フィルター記録のページでバイト数の増減が出てくるようにはできないかな。--Ks aka 98会話) 2014年6月25日 (水) 10:10 (UTC)

賛成です。今さらながら善意かあらしかを問わず、大量のコメントアウトされたら見逃されてしまうことに気づきました。--Gyulfox会話) 2014年6月27日 (金) 23:34 (UTC)

Ks aka 98さん、Gyulfoxさん、他皆さんへ) タグをつける動作にして正式化してもいいでしょうか。タグ名としては「コメントアウト」を考えています。 --whym会話) 2014年8月26日 (火) 14:24 (UTC)
(賛成)--Vigorous actionTalk/History) 2014年8月26日 (火) 14:45 (UTC)
Ks aka 98さん、Gyulfoxさん、Vigorous actionさん、他皆さんへ) 昨日から編集フィルター#30変更履歴一致記録を変更してタグ付けをするようにしました(「最近の更新」をタグでフィルタした結果) --whym会話) 2014年9月5日 (金) 10:23 (UTC)

Hero123対策[編集]

不作成 不作成
目的 「123」で終わるアカウントを作成することを不許可にする。
理由 LTA:HERO123に対応するため
発動条件 「123」で終わるアカウントを作成しようとした時。
対処操作 不許可

LTA:HERO123の最大の特徴は無期限ブロックされると「123」で終わるアカウントを作成することであります。IPで活動することはないようです。善意の利用者にはご迷惑をおかけいたしますが、「123」で終わるアカウントを作成不可にすることで終息させる効果があると思われます。また、特別:不正利用記録にIPアドレスが晒されることで、どのIPから作成されたか一目瞭然でわかるようになります。
なお、LTA:ISECHIKA対策として「恋の」で始まるアカウントが作成されれば自動ブロックがかかるようです。 ——以上の署名の無いコメントは、みんまやノート履歴)さんが 2014-03-23T11:13:48‎ に投稿したものです(miya会話) 2014年8月26日 (火) 14:37 (UTC)による付記)。

  • 反対 2つの理由で反対させていただきます。--Jkr2255 2014年3月23日 (日) 11:28 (UTC)
    • 編集フィルターを使わなくても、特定のユーザー名はブラックリストで禁止可能である。
    • アカウント名自体が有害なわけではなく、むしろこのLTAが使うアカウント名を別なものに変えてしまい、判別しにくくする危険がある(以前に私自身がブラックリストに追加したもので、そのような「効果」を生んでしまい撤去することとなったことがあります)。
  • コメント そもそもそうやってIPを調べようとすることがアウトだと思います。ウィキメディア・プロジェクトではアカウントのIPを本人の許可無く公開しないという方針を取っています。必要があってフィルターを仕掛け、結果的にどのIPが作成したアカウントか分かってしまうのはやむを得ませんが、本来アカウントによって秘匿されるはずのIPを抜こうとする(それを主目的にする)のは財団の方針に引っ掛かる可能性があります(Wikipedia:チェックユーザーの方針#プライバシーに関する方針とチェックユーザー権限の関係)。--Marine-Bluetalkcontribsmail 2014年3月25日 (火) 04:34 (UTC)
    • ×賛成意見もなく、方針に抵触するとの意見もある事から作成は見送りましょう。--Vigorous actionTalk/History) 2014年8月26日 (火) 15:21 (UTC)

IPユーザーへのWelcome[編集]

不作成 不作成
目的 IPユーザーの会話ページに{{Welcome}}をsubst展開(または{{Welcome}}ベタ貼り)しようとした際に警告メッセージを表示する。
理由 そう頻発している問題でもなく、展開された{{Welcome}}のテキストを除去すれば済むのですが、5200バイト程度の増減が生じるので、展開する前に警告メッセージを出せば良いと考えました。Template:Welcome/docでは「IP利用者には使用しないで下さい」となっているため、特に例外なしで発動して構わないと思います。また、IPユーザーの利用者ページを作成しようとすると「IPユーザーの利用者ページや利用者サブページは作成できません」と蹴られるので、会話の方もアカウントユーザーかIPユーザーか判別可能なのではないでしょうか。

なお、メッセージの中でTemplate:Welcomeについて書くこともありえるので、警告文で補足しています。

発動条件 IP利用者の会話ページに{{subst:Welcome}}または{{Welcome}}を含むメッセージを投稿(プレビュー)した時
対処操作 警告文表示
警告文 Template:Welcomeはアカウントユーザーの会話ページ専用です。IPユーザーの会話ページには展開しないでください。文章としてTemplate:Welcomeのことを書こうとしているのであれば{{tl|Welcome}}と書くことでテンプレートを展開させずに済みます。

判別や作成が容易でしたらご検討ください。-- LearningBox会話) 2014年1月10日 (金) 16:21 (UTC)

Daumカフェ,Naverカフェフィルター[編集]

不作成 不作成
目的 標準記事空間に http://cafe.daum.net/XXXX http://cafe.naver.com/XXXX(XXXXは任意のページ)が貼られた時に編集不可にする。
理由 韓国の人物関連の記事にWikipedia:外部リンクの選び方の6(閲覧に有償、若しくはユーザー登録を必要とするサイト。しかも、運営者が操作しないと閲覧できないページもある)と9(SNS(ソーシャル・ネットワーキング・サービス)およびそれに類するもの)、Wikipedia:信頼できる情報源に反するサイトであるにもかかわらず複数の記事にたびたびはられるため。

-- hyolee2/H.L.LEE 2013年4月13日 (土) 22:34 (UTC)

コメント アドレスブラックリストで不足な理由(≒標準空間に限定する理由)はどのあたりにあるのでしょうか。--Jkr2255 2013年4月13日 (土) 22:38 (UTC)
コメント外部リンクの検索結果によると標準記事空間以外への貼付があるためです。(利用者ページとWikipedia:Help for Non-Japanese Speakers/Archive/Questions about finding or editing an article or an imageとノートページへの貼付です。)--hyolee2/H.L.LEE 2013年4月13日 (土) 23:23 (UTC)
コメント 標準名前空間の事情は、その他の名前空間の事情よりも優先されるべきですので、Spam-Blacklistを使ってかまわないと思います。--Ohgi 2013年4月15日 (月) 12:29 (UTC)
  • × 賛成意見もなく、代替措置もあるようですので作成しないことにしましょう。--Vigorous actionTalk/History) 2014年8月26日 (火) 15:21 (UTC)

削除依頼の白紙化[編集]

提案中 提案中
目的 Wikipedia:削除依頼/ 以下ページの白紙化に対して、警告を出して削除審議の妨害をしないようにする。
理由 削除依頼ページを白紙化して、故意に削除審議を妨害するケースが発生しました。このような行為を行った時に注意をして行為を押しとどめることが必要と考えられます。あまりにも繰り返されるのであれば短期ブロック等の対応も必要かもしれません。
フィルター 編集フィルター#28変更履歴一致記録

--S-PAI会話) 2013年2月8日 (金) 11:16 (UTC)

賛成 削除依頼に限らない#ページ(記事)の白紙化(フィルター#2)でも議論されたようですが、結局まとまらなかったようですね。とりあえず編集フィルター#28変更履歴一致記録にて作成してみました。まだ有効にはしていません。Wikipedia:削除依頼/ログ以下のログページの白紙化も検出する仕様にしています。試験をしてみたいので、「削除依頼ページを白紙化して、故意に削除審議を妨害するケース」の例を差分で見せていただけないでしょうか。--Ohgi 2013年2月8日 (金) 20:27 (UTC)
このような例です。削除審議入る前の誤作成対応として{{sd|全般8}}では検出しないようにしてもらえれば幸いです。——以上の署名の無いコメントは、S-PAIノート履歴)さんが 2013-02-09T04:30:26‎Z に投稿したものです(Ohgiによる付記)。
ありがとうございます。試験は成功しました。仕様としては、編集後のバイト数が0バイト、すなわち本当に白紙化されたときしか検出されないようになっています。数文字の文字列に置き換えられたときも検出するという仕様にすれば、編集後のバイト数が何バイト以下という検出方法も可能です。#ページ(記事)の白紙化(フィルター#2)では10バイト未満という検出方法になっていたようですので、そういう方法もありかもしれませんね。10バイト未満なら即時削除タグには反応しないはずです。--Ohgi 2013年2月9日 (土) 08:21 (UTC)
コメント 導入に直接的に反対するものではないですが、Ohgiさん、冒頭の作成手順はきちんと把握されてますか?試験的に作成するのであれば合意形成が必要なのですよ。単にコードを書いてみたいだけなら各編集者のフィルターを使えば済むはずです。編集フィルターで可能な制限の大きさとフィルター編集者の責任の重さをしっかり持ってください。--青子守歌会話/履歴 2013年2月9日 (土) 05:47 (UTC)
冒頭の作成手順は把握していました。雪球として作成したつもりでしたが、雪球なら明示した方がよかったですね。
提案から1週間の合意形成の目的は、ログ取りを開始していいかどうかということにあると思っています。一度提案されたフィルターについて個人的試験フィルターを使ってログ取りを始めるのも、ログ取りの合意形成をバイパスしてしまうという意味であまり良くないことではないでしょうか。
「編集フィルターで可能な制限の大きさ」については、そもそも対処操作をつけていないですし有効にもしていないのです。個人的試験フィルターを使えば問題なかったということであれば、具体的に私の行為の何が「編集フィルターで可能な制限の大きさとフィルター編集者の責任の重さ」を認識していない行為だったのかがわかっていません。--Ohgi 2013年2月9日 (土) 08:21 (UTC)
コメント 本来の手順を無視する必要性が感じられません。提案者と自分の賛成意見しかない段階での雪玉適用は、軽率であると言わざるを得ません。票数の規定を満たしていれば良いというものではなく、もっと根本的な問題です。フィルターを作成した時点で提案から半日も経過しておらず、十分な意見が出たとは言えないし、削除依頼のためにフィルターを作成するという行為は方針で明確に認められた行為や過去の合意に基づくものでもありません。ルール上曖昧な部分であるため、議論の余地が十分に残されています。また、取り急ぎ作成しなければならない状況であれば、理由を述べた上で早急に有効化すべきです。--Marine-Bluetalkcontribsmail 2013年2月9日 (土) 15:54 (UTC)
ご意見として承りました。今後は軽率と言われないような行動を心がけます。--Ohgi 2013年2月12日 (火) 19:10 (UTC)
コメント 1つ気になるのは、削除依頼に対してだけ対処するのに編集フィルターを導入することが果たして必要なのかという点です。編集フィルターは全てのページに対して実行されるわけですから、特定のページ群に対してのみ動作させるには向いていません。過去には管理者投票ページに対しての編集フィルターが検討されて却下されている(取り下げられている)経緯があります。長期的には新たに導入するよりは、WP:EF/R#ページ(記事)の白紙化(フィルター#2)を活用すべき案件でしょう。逆に今現在進行形で荒らされているため緊急的にフィルターが必要であるのであれば議論なしにとりあえず導入すべきです。--青子守歌会話/履歴 2013年2月9日 (土) 05:47 (UTC)
削除依頼が白紙化される意味は、他のページの白紙化と若干変わってくると思います。少なくとも標準名前空間の白紙化とは別のタグをつけたいです。--Ohgi 2013年2月9日 (土) 08:21 (UTC)
コメント 削除依頼の白紙化のみを特別扱いする必要性がよく分かりません。タグとは「(あとで)区別して見やすいように」つけるものなのですから、「白紙化」として分離してあれば再検討の手間は十分ではないのですか?少なくとも名前空間ごとにフィルタリングはできるのですし。en,fr,deなど主要な大規模ウィキも見てみましたが、少なくともこのような「編集回数が全体から見ればごくわずかな比率でしかないページ」に対してのみを対象とした編集フィルターが導入されている形跡はありません。本当に独立したフィルターでしか実現できないのか、少なくとも客観的事実(観測データなど)をもって説明がなされるべきです。--青子守歌会話/履歴 2013年2月12日 (火) 23:13 (UTC)
なにを私にお尋ねかよくわからないんですが、要するに「ログ取りを開始するべきだ」とおっしゃっているんですか?--Ohgi 2013年2月13日 (水) 00:41 (UTC)
コメント ログをとらないとわからないほど微妙な件数なのでしょうか?特定のページ群に対応するには不向きな編集フィルターをあえて使うべきということは、現状でも誰かを説得できるだけの明らかな根拠(必要性)があるのではないのですか?--青子守歌会話/履歴 2013年2月14日 (木) 13:47 (UTC)
私に何をお尋ねか、あるいは何を求めていらっしゃるのか、よくわかりません。--Ohgi 2013年2月14日 (木) 18:24 (UTC)
コメント 聞いているのは、「『白紙化』として分離してあれば再検討の手間は十分ではないのか?」「本当に独立したフィルターでしか実現できないのか?」「特定のページ群に対応するには不向きな編集フィルターに対してあえて使うなら、その根拠を個人感覚ではなくて誰かを説得出来るだけの根拠があるのではないのか?」といったことです。確かに、特に手順をすっ飛ばして雪球条項を適用できるぎら明らかだと判断されたOhgiさんには確固たる答えが用意できるものと期待していますが、別にOhgiさん個人に質問しているのではなくて、本フィルターを(このまま)運用すべきという方に意見を聞いてみたいですね。--青子守歌会話/履歴 2013年2月15日 (金) 00:02 (UTC)
対象ページの少ない処理や発火頻度の低い処理には「不向き」かという点についてのみコメントします。月毎編集回数でいうと日本語版は30万程度 [1]ですが、それより多い [2] のコモンズには、対象を非常に狭くとったフィルターがあるようです。65番COM:OTRS/Noticeboardのみ、7番COM:Sandboxのみを対象にしたフィルターです。どちらも2年以上にわたって有効化されていて、対象は極端に編集数が多いページではありません(多くて1日10回程度)。こうした事例をみますと、対象ページの少なさや発火頻度の低さに関しては、特にマイナス要素にはならないのではないでしょうか。直感的にも、編集操作の回数は閲覧操作より非常に少ないでしょうから、編集によって発火する処理の時間は(よほどでなければ)気にしなくてもいいように思います。具体的にどういった事情を念頭に「不向き」とおっしゃったのかがよく分かりませんでしたので、別のお考えがありましたらご説明いただきたいです。 --whym会話) 2013年2月21日 (木) 14:33 (UTC) 一部数字の解釈の訂正と誤字の訂正をしました。 --whym会話) 2013年2月22日 (金) 11:51 (UTC)
コメント 今日も削除審議を白紙化する荒らしが発生しました(今回は審議終了済み)[3][4][5][6]。このような荒らしに対してより重い処理(編集の却下やブロック処理)を行うのであれば分ける意義は十分にあると思量されます。通常の記事の場合は初版投稿者の白紙化もありますし利用者ページなら本人都合による白紙化も当然あり得ますが。--S-PAI会話) 2013年2月17日 (日) 05:27 (UTC)
コメント 青子守歌さんから「編集フィルターに不向き」とする理由は示されてないようですので、あと数日待ってそれでもコメントがなければ、このままログ取りを始めようかとおもっています。--Ohgi 2013年3月7日 (木) 10:58 (UTC)
有効化し、ログ取りを始めました。--Ohgi 2013年3月16日 (土) 14:10 (UTC)
さて、対処操作はどうしましょうか。個人的には不許可ではなく警告を想定していましたが、他の方のご意見をお尋ねしたいところです。--Ohgi 2013年3月16日 (土) 14:10 (UTC)
  • (苦言)フィルターはわずかとはいえMediaWikiの動きを遅くするものですよね。メリットとデメリットをはかりにかけて、メリットがはるかに大きい場合・デメリットが無視できない場合のみ、使うべきものと思います。賛成が1票しかついていないフィルターを有効化するのはいかがなものか。賛成が1票しかついていないということは、メリットとデメリットを比較して、どちらとも言えないと考えている人(私もです、削除依頼の白紙化は名誉棄損やプライバシー侵害が発生するような案件じゃないですよね)が大半だと考えるべき、フィルター編集者として慎重さが足りないと思われます。今後はよほどの緊急性が無い限り、フィルターの制作、特に正式化に「雪玉」を用いないでいただきたい。◆とはいえ、有効化する前にこちらにコメントしなかったので今すぐ止めろとは言いませんが、ログ取りを1か月行って、毎日引っかかるようなら、それから改めて対処操作を考えればよいでしょう。1週間に1、2件(同じページに対するものや同じユーザーによると推定されるものは、何回白紙化されても1件という意味)程度であれば、このフィルターは必要性がそれほどなかったと考えます。--miya会話) 2013年3月17日 (日) 00:36 (UTC)「今後はよほどの緊急性が無い限り」を追加--miya会話) 2013年3月17日 (日) 00:43 (UTC)
    • 「雪球を使った作成」に対する苦言なのか、「賛成が1票しかついていないのに有効化したこと」に対する苦言なのか、あるいはその両方に対する苦言なのか、明確にしていただけますか。前者については反省しております。後者の経緯は、前者について反省し、今度は十分な期間を経た上で、予告までして、有効化した、というものです。このフィルターを有効化すべきでなかったということであれば、少なくとも予告の後に1週間以上期間があったのですから、この期間にコメントをいただけないでしょうか。後者について「慎重さが足りない」とおっしゃるのであれば、有効化の前に予告までしておりますので、これ以上どう慎重にすればいいのでしょう。それと、あるフィルターを導入するメリットは大きいが、そのフィルターを導入するデメリットが無視できない場合にこそ、フィルターを導入すべきか否かどちらともいえなくなるのではないでしょうか。今回のフィルターを導入するデメリットとしては、他のフィルターと同様ページの保存に時間がかかってしまうことを想定していますが、無視できるレベルにあると考えます。--Ohgi 2013年3月17日 (日) 17:19 (UTC)
      • 失礼、少なくとも有効化については「雪玉」扱いではなかったですね、紛らわしいことを書いてすみません。◆「これ以上どう慎重にすれば」とのことですが、「必要性」を問われたらその必要性を相手もしくは第三者に理解できるように示してください。フィルターで対応が可能である、とフィルターで対応するほどの必要性/重要性がある、は別物です。提案者には申し訳ありませんが正直なところ、この提案に関しては、フィルターを用いなければならないほどの必要性/重要性がいまだに明確に示されていないと私は考えています。◆現在進行中の削除依頼の白紙化はそれほど多発しているわけではない印象ですし、見ている人が多いのですぐさま戻せます。終了した削除依頼はぶっちゃけ気付かれずに放置されても実害はありませんが、どうしても問題であれば終了した削除依頼をすべて保護するという対応も可能なわけです。--miya会話) 2013年3月18日 (月) 05:49 (UTC)
        • miyaさんにとってフィルターは劇的なまでの効果がないと使用してはならない神聖なものなのでしょうか。たとえば、対処操作を不許可にすれば、少なくとも差し戻しの手間がなくなります。あるいは、警告を出すことにすると、白紙化する人に削除依頼へ反対する方法や復帰を依頼する方法をご案内することができるでしょう。会話ページにそれをご案内する手間がなくなります。たしかに発動回数は少ないかもしれませんが、こういう細かいことにもフィルターを使うべきだと思います。「問題であれば終了した削除依頼をすべて保護する」のは、フィルターを使った手間の解消に逆行するものであり、それこそフィルターを使って実現すべきものでしょう。--Ohgi 2013年3月18日 (月) 07:12 (UTC)
          • 「故意に削除審議を妨害するケース」以外に、削除依頼ページを白紙化する事例というのは考えられないのかな。依頼ページ自体に、誰かの権利侵害があるような場合もあるでしょうし、不慣れな利用者が自分の作った記事を削除されそうになっていて、どうしたらいいのかわからないから白紙化してしまったというようなこともあるでしょう。対処操作としては、不許可でも警告でもなく、善意にとった案内文が必要だと思います。審議期間中に白紙化しても、それほどの妨害にはなりません。気付く人はいますし、差し戻しがされるでしょう。差し戻しはたいした労力ではないですし、削除依頼の白紙化は発生件数自体も少ないですよね。それなら、多少の労をいとわずに対話したほうが、いい結果を生むとも考えられます。警告が出たところで、意図的に白紙化しているのなら、止めることは、それほど期待できませんから、ブロックの上で対話を試みるということになるのではないでしょうか。閉じた後なら、白紙になったものを放置したところで、そうそう困ることはないです。閉じた後に白紙化するのを防ぐなら、管理者としては手順の中で保護の操作ができますし、botを使ってもいいんじゃないのかな。保護しておけば、白紙化以外の改竄も防ぐことができます。そうした対応ではなく、フィルターを使うメリットがあるかどうか。--Ks aka 98会話) 2013年3月21日 (木) 17:23 (UTC)
            • 「警告」とは編集フィルターの対処操作としての「警告」であり、中身が案内文だろうと注意喚起だろうときつい警告だろうと対処操作は「警告」と言います。さらに、「故意に削除審議を妨害するケース」以外も私は想定して、「警告を出すことにすると、白紙化する人に削除依頼へ反対する方法や復帰を依頼する方法をご案内することができる」という表現をしました。「対処操作の『警告』を使ってご案内を出す」と表現したほうがわかりやすかったかもしれませんね。
              終了した削除依頼をすべて保護するという件は、削除者はどうするのか、管理者権限をbotに持たせるのか、など解決しなければならない問題が多数あります。仮にbotにやらせたとしても、大量に保護をかけるためにサーバー負荷が増えるという意味で、サーバーは重くなります。サーバーが重くなるのは編集フィルターを使って過去の依頼を編集できないようにしても同じことですし、編集フィルターを使えば一度構文を読みこませるだけですぐに過去の依頼を編集できないようにすることができます。以上の理由から、もしも終了した削除依頼を編集できないようにするのであれば、編集フィルターを使うべきであると考えられます。
              「そうした対応ではなく、フィルターを使うメリットがあるかどうか」ということですが、フィルターは「そうした対応」ができない場合にのみ使用される最終手段なのでしょうか。どうもフィルターが腫れ物のように扱われているように思えてならないのですが、フィルターはもっと活用していいものだと考えています。--Ohgi 2013年3月24日 (日) 01:38 (UTC)
              • 頻度とその警告文次第ってことで。Miyaさんもそれでいいですか? 頻度が低いなら「フィルターを使った手間の解消」自体が成立しない。会話ページでのやり取りが必要なあらゆる局面でフィルターの挙動がマイナスに働かないなら導入に反対する理由はない。その他はノートで。--Ks aka 98会話) 2013年3月24日 (日) 08:54 (UTC)
                • 「頻度とその警告文次第」で結構です。毎日起きる事でしたら、そうしてどんな原因による白紙化にも対応可能な警告文が出せるのなら、確かにフィルターがあってもいいかもしれません。ただ、月に1-2回しか起きない事象にフィルターを用いる必要性は無いでしょう。白紙化の原因が色々ですので警告文はどのケースにも当てはまるものでなくてはなりませんが、もし「理由を示さずに白紙化しないでください」であれば、削除依頼限定のフィルターではなく、全空間対象の編集フィルターでいいだろうと思います。--miya会話) 2013年3月25日 (月) 05:23 (UTC)勘違いしていたリンクを修正しました--miya会話) 2013年3月25日 (月) 12:54 (UTC)
  • (暫定反対)「WP:EF/R#ページ(記事)の白紙化(フィルター#2)を活用すべき案件」という指摘に対して、ごく限られたページを対象とする必要性も明確でなく効果的な警告も示されていないため(対象の広さ:狭い、頻度:1週間で1-3件程度、深刻さ:名誉毀損・プライバシー侵害の虞はなく読者の目にも触れないページ、効果:警告文も未提案)、現段階ではこのフィルターに反対せざるを得ません。◆一つくらいなら必要性と効果が明確でないフィルターがあっても無くてもよいかもしれませんが、このレベルをOKにしてしまえば、今後これと同程度の必要性/重要性のフィルターが多作される可能性が否定できないためです。◆なお、作成者以外のフィルター編集者が3人以上、このフィルターの重要性を認めて賛成票を投じれば、この反対票を取り下げる用意があります。ひとり以上賛成票を投じれば、この反対票は無かったものとしていただいて結構です。--miya会話) 2013年4月1日 (月) 06:13 (UTC) 「3人以上」は現実的でないと思い返して「ひとり以上・・・」に修正。--miya会話) 2013年4月3日 (水) 05:47 (UTC)
    • 警告文の提案が遅れまして申し訳ありません。近いうちに提案します。「今後これと同程度の必要性/重要性のフィルターが多作される可能性」については、このフィルター自体の問題ではありませんので、このフィルターに問題があるかどうかを検討していただきますようおねがいいたします(そもそも「今後これと同程度の必要性/重要性のフィルターが多作される」ことは問題でさえないと思います)。--Ohgi 2013年4月4日 (木) 13:28 (UTC)

遅くなりましたが、警告文を提案します。

削除依頼を白紙化する人は、削除に反対したいのであろうと考えられるため、削除への反対方法に特化した説明としました。--Ohgi 2013年4月9日 (火) 08:02 (UTC)

  • コメント 「依頼ページ自体に、誰かの権利侵害があるような場合」(Ks aka 98さん 2013年3月21日 (木) 17:23 のコメントより引用)はどうなるのでしょう。and/or「特筆性無し!」「露骨な宣伝!」「著名性なし!」など、酷い言葉が書き連ねられた削除依頼(削除済み)をご本人や良かれと思って投稿したファンが追い詰められた思いで白紙化するケースも考えられます。--miya会話) 2013年4月15日 (月) 11:46 (UTC) 追記:あるいは、企業の広報担当者が不用意に自社記事を投稿して散々こき下ろされて目的外の宣伝として削除されて、削除依頼の文面が企業にとって大変なイメージダウンになりかねないと白紙化する、というケースも考えられます。ウィキペディアから見れば自業自得にも見えますが、酷いことを書かれた削除依頼の文面を未来永劫ネットに晒し続けられるのは当事者にとっては放置出来る事ではないでしょう。誹謗中傷するものだからそのページを消してくれという依頼がOTRSにしばしば寄せられますが、自分で直接白紙化する人もいるだろうと考えられます。--miya会話) 2013年4月15日 (月) 12:10 (UTC)
    • たしかに、その点が抜けていたように思います。また、依頼者が即時削除を意図して白紙化する可能性もあるかもしれません。以下に提案し直します。--Ohgi 2013年4月15日 (月) 12:29 (UTC)

このような形でInfo-jaに言及するのは問題ありませんでしょうか。警告文にまだ抜けている点があればご指摘ください。--Ohgi 2013年4月15日 (月) 12:29 (UTC)

コメント 削除議論が対象に対する誹謗中傷にあたるという理由で削除依頼ページが削除依頼に出されて削除された例を知りませんーそういうことはありうるんでしょうか。Info-jaに相談・・・依頼があれば削除依頼を過去ログ化してもいいのならInfo-ja に回していただいて結構ですが、現状ではInfo-jaとしては何もできない可能性が高いですよね?たらい回しになってしまうのはどうかと思います。逆に、依頼があれば過去ログ化できるなら、なにもInfo-jaに回す必要もないですよね?存命人物や活動中の組織についての削除議論は当事者からの要請があれば過去ログ化できると合意形成し、依頼場所を整備してそこへリンクなさるなら、それなりに意義があるとも思います。◆「まだ抜けている点」?「上記のどれにも当てはまらない場合」が抜けているかもしれません。--miya会話) 2013年4月17日 (水) 11:33 (UTC)

10万バイト以上の編集を禁止(緊急措置)[編集]

作成済 作成済
目的 10万バイト以上の情報を追加する編集を不許可とし、ブラウザのクラッシュを防ぐ
理由 本日、0時から1時頃(日本時間; UTC: 28日 15時-16時頃) にかけて、利用者ページを複数回展開したと思われる巨大な情報を追加する編集が相次ぎ、ページを開いた瞬間にブラウザ自体がクラッシュする可能性もあることから、緊急措置として AbuseFilter を編集の「不許可」で設定しました。また、下記の #和暦の展開に関する警告 に引っかかったものがなかったので、特別:不正利用フィルター/24 を使いまわしすることとしました。設定直後に該当する編集が止んだように思われたため、既に無効化しております。また、こちらのフィルターに引っかかったものは現在のところありません。

-- Hosiryuhosi会話) 2012年10月28日 (日) 17:22 (UTC)

詳細は管理者メーリングリストに投稿しましたが、フィルターが非常に有効な対策となりそうです。発動条件は再考の余地があるかもしれませんが、少しの間だけ有効にして様子を見ることはできないでしょうか。--Marine-Bluetalkcontribsmail 2012年10月28日 (日) 17:28 (UTC)
本日(2012年12月4日 (火) 00:28 (UTC))、問題投稿が繰り返されるため、少々条件を変えて再度有効化してみました。--Hosiryuhosi会話) 2012年12月4日 (火) 00:28 (UTC)

和暦の展開に関する警告[編集]

作成済 作成済
目的 {{和暦}} テンプレートを展開するIP利用者への警告
理由 対話を促し、編集の強硬をお止めいただくため。

事後報告となりますことを、予めお詫び申し上げます。大阪ocn IPユーザーによって警告と対話を無視した、{{和暦}}テンプレートの展開作業が短時間の間にブロックをしても即座にIPを変えて繰り返されて効果がないため、特別:不正利用フィルター/24 を緊急措置的に作成致しましたが、作成直後(引っかからず)に作業が停止されたため、現在は無効化しております。一応こちらのページにて報告とさせていただきます。-- Hosiryuhosi会話) 2012年10月3日 (水) 10:17 (UTC)

行き止まりページの防止[編集]

提案中 提案中
目的 標準名前空間で新規に作成されたページのうち、標準名前空間へのリンクがないページに警告を出すタグをつける
理由 即時削除されるページやサブスタブ減らすため見つけやすくするため

--プログラムノート/履歴/ログ 2011年10月31日 (月) 13:02 (UTC)

  • コメント 目のつけどころはいいんじゃないかと思いますが、「標準名前空間へのリンクがないページ」に「即時削除されるページやサブスタブ」が多いということを示すデータ等がないと警告を出すことには賛成しかねます。あるいは、リンクがないということで、その記事にWikifyが必要であるということを示すことができるかもしれませんが、そういう目的であれば編集フィルター#1変更履歴一致記録の「カテゴリを含まない記事の作成」が使える可能性があり、必ずしもリンクがないことそれ自体に警告の必要性があるとは思えません。とりあえず、リンクがないページを検出するフィルターを作って、ログだけ取ってみてもいいかもしれません。--Ohgi 2011年10月31日 (月) 18:18 (UTC)
  • 提案する対処操作を「警告」から「タグ付け」に変更しました。--プログラムノート/履歴/ログ 2011年11月2日 (水) 12:58 (UTC)

会話ページのコメントの除去の防止[編集]

提案中 提案中
目的 会話ページで、警告などを勝手に除去できないようにする。
理由 会話ページでのコメントの除去が問題となっているため。

--プログラム会話) 2011年7月24日 (日) 14:46 (UTC)

コメント 過去ログの識別方法は"過去ログ"があるかないかでいいでしょうか。--プログラム会話) 2011年7月24日 (日) 14:46 (UTC)

  • 発動条件が難しいんじゃないかと思います。どのような発動条件を想定していらっしゃいますか。--Ohgi 2011年8月4日 (木) 20:10 (UTC)

取り下げ 合意の上での除去を検出できないため、本提案は取り下げます。--プログラムノート/履歴/ログ 2011年9月9日 (金) 13:08 (UTC)

依頼関連[編集]

提案中 提案中
目的 投稿ブロック依頼、削除依頼、チェックユーザー依頼で依頼資格を満たしてないユーザーを編集不可にする。
理由 ソックパペットによる多重投票や、報復依頼を阻止するため。初心者の中には方針をしっかり読まずにこれらのページを誤って編集する方もいます。その人たちにも注意する必要があると思います。

--ウメサキシュンタ 2011年5月8日 (日) 09:05 (UTC)

反対 編集フィルターは、すべてのページをフィルターの対象とします。そのため、特定のページに行われる問題のある編集の対処には向きません。このフィルターは特定のページを対象としています。そのため、他の方法を考えるのがいいでしょう。--プログラム会話 | 投稿記録 2011年5月12日 (木) 12:06 (UTC)

  • (一部賛成)提案者がソックパペットなのは別として。削除依頼やチェックユーザー依頼、管理者への立候補は、多重アカウント以外のすべての利用者が編集可能ですので対象とすべきではありません。編集フィルターには、多重アカウントかどうか判定する術がないので、多重アカウントの編集不許可も実現不可能であると考えられます。
    投稿ブロック依頼はコメントさえできない利用者がいますので、コメントの資格のない利用者の編集を不許可とするようなフィルターについては賛成します。--Ohgi 2011年8月4日 (木) 20:10 (UTC)

GRIMMフィルター[編集]

提案中 提案中
目的 GRIMMによる荒らしへの対応
理由 数年前よりも荒らしが行為が深刻化しており、ブロック対応では食い止めきれません。スパムブラックリストでも効果のないパターン(h抜きや内部リンクなど)で荒らしていますので、フィルターによる何らかの抑制が出来ないものかと考えます。現在編集フィルター#17変更履歴一致記録で実際にスパムリンク追加の検出を試験中ですが、3月31日の変更以後、誤爆はないようです。

-- Marine-Bluetalkcontribsmail 2011年5月3日 (火) 15:56 (UTC)

ページの置換[編集]

提案中 提案中
目的 荒らしの発見
理由 深刻な荒らしの場合、ページを置換している場合があります。対処アクションは警告とタグ付けを考えています。

--プログラム (会話 | 投稿記録) 2011年2月4日 (金) 09:34 (UTC)

名前空間によると思います。標準名前空間などでは問題ですが、利用者ページはその利用者ご本人が全く別のページに編集されることもありますので、利用者ページの扱いを考えたほうがよいかもしれません。--長月みどり 2011年2月4日 (金) 19:59 (UTC)
確かにそうですね。利用者ページでは問題無さそうですから対象外にしましょう。--プログラム (会話 | 投稿記録) 2011年2月5日 (土) 12:48 (UTC)
コメント 発動条件をどうするのか(どういう条件をもって「ページの置換」とみなすのか)について私はよい案を考えつきません。むしろページの白紙化(あるいは小さくしすぎる)という条件(c.f. #ページ(記事)の白紙化(フィルター#2))とほぼ同等とみなすのがよいのではないかと思います。--青子守歌会話/履歴 2011年2月12日 (土) 20:17 (UTC)
コメント {{subst:Sakujo}}による置換もありますので、それも除外すべきかと思います。あと、removed_lines == old_wikitext のようなコードは使えないのでしょうか。--Ac-dc 2011年2月15日 (火) 23:02 (UTC)
コメント removed_linesは「除去のあった行」ですので、例えば「本日は晴天なり」から「晴天」のみを除去して「本日はなり」としても、old_wikitextと一致してしまいます。ですから、そのような実装では厳しいといわざるをえないでしょう。--青子守歌会話/履歴 2011年2月16日 (水) 02:12 (UTC)

新規利用者の会話ページへの{{Welcome}}推奨のお願い[編集]

提案中 提案中
目的 新規利用者にウェルカムメッセージがなされない可能性を減らす
理由 いま現在、新規利用者が投稿するとbotによって{{Welcome}}が貼られます。しかし、新規編集に問題がある場合など、他のユーザーが先に会話ページに書きこんでしまうと、貼付けはなされません。ユーザーによっては削除依頼の案内などの前に{{Welcome}}を手で貼る人もいますが、何の案内もないままいきなり削除依頼への誘導だけ置かれるという、新規利用者に対してかなり不親切な対応になってしまっていることがちらほら見られます。ともすれば新規利用者いじめとも解釈されうる現状を改善するため、利用者の会話ページを他者が新規作成するときは、{{Welcome}}を使っているかどうかチェックして、なければ注意を出す、ということをしてみてはどうでしょうか。

-- Jkr2255(Talk/History) 2011年2月4日 (金) 02:09 (UTC)

コメント 発動条件として「他者の会話ページを新規作成しようとして、作成しようとしている内容に{{welcome}}があるかどうか」を指定することは可能だと思います。ただし、これをフィルターでやるべきなのか(スクリプトなどで自動挿入すべきではないか)、あるいは、そもそもwelcomeが必要なのかどうかについて疑問もありますので、コメントのみにしておきます。--青子守歌会話/履歴 2011年2月12日 (土) 20:21 (UTC)
コメント 悪くはないと思いますが、welcomeは促されるべき性質のものなのかどうかちょっと悩みます。発動条件や案内のメッセージ次第でしょうか…。いきなり靴下ブロックのお知らせを貼るときに「{{welcome}}貼ってね」とか言われたら余計なお世話ですし。あと、実際にやるなら「{{ようこそ}}」にも配慮していただきたいです。--Marine-Blue [ 会話 履歴 電信 ] 2011年2月20日 (日) 03:07 (UTC)
コメント ページ作成の場合{{test5}}系のtemplate等の場合は、{{welcome}}又は{{ようこそ}}は場合によっては要らないので除外(t5系の貼り付けは管理者が推奨される事から、管理者判断で必要であれば{{welcome}}を貼るでしょうし)。それ以外の場合は貼り付けのお願いをするというのではどうでしょうか?あと、{{test3}}・{{test4}}辺りではどうするのかなど詰めて行けばいいのでは?--Vigorous actionTalk/History) 2011年2月20日 (日) 03:20 (UTC)

機種依存文字が記事名に含まれているものを警告[編集]

提案中 提案中
目的 JIS X 0208にないものは使用せずトウ小平のようにカタカナもしくはひらがなを使用することになっています。髙や﨑も使用出来ないので高や崎を使用することになってます。♥も使用出来ないです。このような記事名に機種依存文字が含まれる場合警告出来ないでしょうか。
理由 中国人や韓国人を作成するとき使用できない漢字を使用してしまうことがあります。使用できない文字を使用した場合警告してほしい。

-- --Rain night 2011年1月13日 (木) 07:39 (UTC)

反対 反対というか、フィルターの技術的に不可能だろうと思います。何度か要請があったのでどうにかできないか試してみましたが、文字コードを判別する術がありません。そしてついでに申し上げると、現在のjawpではUnicodeBMP範囲内である文字なら♥であっても作成可能です(少なくとも即時削除されません)。というわけで、反対票としてカウントしておいてください。--青子守歌会話/履歴 2011年1月26日 (水) 08:04 (UTC)
反対 少なくとも現在UnicodeBMP範囲内であればリダイレクト化は認められていますし、そうでなければMediaWiki:Titleblacklistで作成拒否されるため問題になることはない。そもそも、Unicodeの漢字の並び順から該当するのを抜き出すのは技術的に無理だと思います。(\x{4E00}=「一」(JIS X 0208規定)/\x{4E01}=「丁」(JIS X 0208規定)/\x{4E02}=「丂」(JIS X 0208規定外)/\x{4E03}=「七」(JIS X 0208規定))。よってこれは編集フィルターで行うものでないとして反対票とします。--S-PAI 2011年5月13日 (金) 21:30 (UTC)
反対 人力で行える範囲でやればいいのではないでしょうか。--ますや 2011年10月20日 (木) 09:47 (UTC)

署名忘れ防止[編集]

提案中 提案中
目的 読んで字のごとく。ノートとかだと結構署名忘れる方多いですし、私も結構忘れますし。最初は非承認ユーザーのみにしようかと思いましたが、承認済みユーザーでも実態は新規とそう変わらない子は結構いるかと思い直しまして。
理由 Wikipedia:署名のより良い遂行のために
発動条件 名前空間「ノート」及びページ名「Wikipedia:削除依頼/*」、「Wikipedia:保護依頼」「Wikipedia;井戸端」への投稿で~~~~が含まれないもの
対処操作 警告
警告文 現在の草案(2つ) 利用者:Kabisuke/署名忘れテンプレ草案

「てめぇ実際にコードも書けねえのに何言ってくれてんの仕事増やすな」されることも4割強ほど覚悟してますが、飽くまで提案です。こういうのって可能ですか?警告文は個別に、「ここ署名が必要なページっぽいけど大丈夫ですか?いや大丈夫ならいいけど」的にソフトタッチなものを作れればいいと。勝手に作ってみた草案:利用者:Kabisuke/署名忘れテンプレ草案 -- kabisuke 2010年9月23日 (木) 19:43 (UTC)

コメント 方向性としては十分ありだと思います。add_linesが~~~~を展開してしまうので、ちょっとすぐには発動条件が思いつきません。もう少し突っ込んで、追加行に「自分の利用者ページへのリンクがない」とかならできそうですが、いずれにしても、過去ログ化とか前の発言の微修正とか、投稿時に必ず署名が必要なものばかりではないので、そのへんをどう回避するか(あるいは誤差として無視して、警告文にそれを書いておくのか)、もう少し詳しく考えないといけないかなと思います。--青子守歌会話/履歴 2010年9月24日 (金) 03:32 (UTC)
コメント 発動条件はプログラムの都合に応じて支障のない範囲で変えてしまって構わないと思います。確かに、普段使う署名の形式に拘らなくても、利用者ページへのリンクさえあれば問題ないですね。 誤爆については無視する方針で考えていました。が、緊急度が低いとは言え警告は警告ですから、回避案があればそれを執るに越したことはありませんね。 誤爆を無視する場合用に、更に口当たりまろやかな第二案も利用者:Kabisuke/署名忘れテンプレ草案に勝手に作ってみました。ご意見募集。--kabisuke 2010年9月24日 (金) 15:31 (UTC)
コメント これは面白いですね。おそらく利用者ページへのリンクの有無を基調に、名前空間などを使って場合分けして判定することになるでしょうか。誤警告については、例えば「テンプレートの大きさを小さくする」とかいう形で、それほど邪魔にならない形で表示する、という選択肢もありそうです。詳細を少し考えるための参考として、英語版にen:User:SineBotという、署名忘れをRCから自動で検出して補完しに来てくれるボットがいます。ボットがどういう判定アルゴリズムを使ってるか仕組みかよく分からないですが、フィルター作成の参考にはなるかもしれないです。--Was a bee 2010年9月24日 (金) 15:45 (UTC)
コメント このフィルターのように「ある必須動作があることを周知させる」目的のものの場合、テンプレート:編集画面の注意文を使う手もあります。発動条件が絞り込めず誤作動が多そうな場合、これを使う方向ではいかがでしょうか。--青子守歌会話/履歴 2010年9月24日 (金) 17:08 (UTC)
コメント すっかり放置してましたすみません。こんなテンプレートがあるとはついぞ知りませんでした。編集フィルターと比較するとどちらがサーバに負担をかけるものなのか想像もつきません。LQTの方についてはどうすればいいのかすら皆目見当が付きませぬ…身に余る議題だったかもしれない。編集フィルターでガン押ししたほうがいいのか、他の手段をとったほうが効率的なのか、こういう事に詳しい方のご意見強く求む。--kabisuke 2010年10月6日 (水) 16:09 (UTC)
コメント わたしがウィキペディアの編集を始めたころは、署名のやり方を知りませんでした(投稿したら自動的にはいるものだと思ってました)。そのような経験がありますので、方向性としては賛成であったらいいなと思います。以前のわたしのように署名の方法がわからない方はウィキペディアにまだあまり慣れていない初心者さんに多いと思いますので、そのような方へのお知らせの意味でも有用でしょう。--長月みどり 2010年9月24日 (金) 19:28 (UTC)
コメント そういえば、絶対に「署名を忘れない方法」を思い出しました。議論にLQTを使えば、署名は自動補完されるので、「忘れる」とか「知らなくて署名していない」ということもなくなると思います。こちらの導入も検討されてはいかがでしょう?--青子守歌会話/履歴 2010年9月25日 (土) 03:34 (UTC)
コメント 私も賛成です。ついうっかり付けることを忘れることも人間ですからあるでしょう。そういう機能があれば私は助かります。--・・・・ 2010年10月1日 (金) 03:59 (UTC)
コメント不削除ノートなど、署名を必要としない編集もあるため、警告だけということでしたら賛成します。私もうっかり忘れることが時々ありますし、とても有用だと感じます。--Himetv 2010年10月6日 (水) 16:45 (UTC)
コメント 先にも書きましたが、発動条件が非常に難しいので、今のところ、私は積極的に賛成&推進することはできません。みなさん(特にフィルター編集者の方)、よい条件が思いつきましたらご提案していただければと思います(ところで、みなさん賛成なのに{{賛成}}がついてないのは、こういうところがあるんでしょうかね・・・)。--青子守歌会話/履歴 2010年10月6日 (水) 18:13 (UTC)
コメント 青子守歌さんのおっしゃるように、技術的な面で難しいのかもしれないと思いコメントとさせていただきました。署名するのを知っていて忘れることへの対策だけでなく、署名の必要性やその方法をご存じでない方に対する告知もできればと思います。技術的に難しそうですので、テンプレート:編集画面の注意文の活用も考えられるでしょう。--長月みどり 2010年10月6日 (水) 18:49 (UTC)
コメント署名のない文では誰が書いたかわからないので、自動的に付くようにするということもできたらいいですね。--ますや 2011年10月20日 (木) 09:53 (UTC)

refが追加されているのに、referencesがない[編集]

提案中 提案中
目的 脚注を示すrefタグが追加されているが、脚注を表示するreferencesタグ、あるいはそれと同等な働きをするテンプレート({{reflist}}など)がない場合に、その編集を許可せず、referencesを追加するように求める。
理由 refタグは、referencesがないと正常に働かず、そのような状況を防止する必要があります。

--青子守歌会話/履歴 2010年9月17日 (金) 21:20 (UTC)

コメント 現状でも、そのような編集をしようとすると、警告が出たりします(e.g. MediaWiki:Cite error refs without references)ので、あえてフィルターで制限する必要はないかもしれません。しかしそれに気づかない編集もいくつか見受けられますし、そのような場合には投稿できないようにしておくと、より気づきやすくなると思います。--青子守歌会話/履歴 2010年9月17日 (金) 21:20 (UTC)
コメント 数自体そう多くなさそうですので、様子見でMediaWiki:Cite error refs without referencesHelp:脚注へのリンクを表示する、ということはできないでしょうか。現在の状態だとエラーが出たのは分かっても、解決法が書かれてないのでそのまま放置してしまう、という人もある程度いるんじゃないかと思います。Google検索でかかった記事を対象に脚注節の追加を実験的にやってみた所[7]。検索にかかった範囲では50件ちょっとでした(他にももっとあるかも知れませんが)。--Was a bee 2010年9月19日 (日) 12:13 (UTC)
コメント たぶん、この「refがあるのにreferencesがない」問題に対しては、解決方法はたくさんあって、システムメッセージをもっと目立たせて親切にするというのもそうですし、Was a beeさんがされたように、botで検出して自動追加しても、同じ結果が得られると思います。編集フィルターによる不許可は、その解決方法の1つに過ぎません。ゆえに、あとは「ほかの方法で十分だから、フィルターなんて要らない」となるか「やれる対策をしておくに越したことはないから、フィルターをつけよう」となるかだと思います。--青子守歌会話/履歴 2010年9月19日 (日) 14:58 (UTC)
コメント ほかの方法で一定の効果があり、多少の漏れがあっても実害は大きくない、と考えられる場合は、フィルター導入はよくよく考えるべきだと思います。--miya 2010年9月24日 (金) 10:15 (UTC)
コメント まぁ、思いついたフィルターをブレストのように、とりあえず案を出して行っている状況なので、特に編集フィルターでなければならないということはないと思います。が、「ほかの方法で」とおっしゃるのでしたら、その「ほかの方法」が実現するようにどこかで具体的に話を進めていかなければならないだろうと思います。--青子守歌会話/履歴 2010年9月24日 (金) 17:03 (UTC)
(追記)たぶんもうお分かりかと思いますが、このフィルターに限らず、基本的に、編集フィルターと同じ機能を、jsによるスクリプトに持たせることは可能です(たぶん、自動操作取り消しも可能?)。ただし、スクリプトにするとメンテナンスが大変&整備も大変で、それを簡単に出来るのがこの編集フィルターである、と考えてよいと思います。なので「スクリプトで出来るなら、スクリプトでやれ」という方向性になると、編集フィルターは何も作れなくなる恐れがあるので、その辺りはよくご考慮いただければと思います。--青子守歌会話/履歴 2010年9月24日 (金) 17:12 (UTC)
コメント 上で脚注節の追加作業をしてから6日後に再検索して作業を行ってみた所、18件が編集対象となりました[8]。検索にかかったのは100件近くあり、残りの多くはすでに節が追加ずみでした。どうもrefタグだけ足していく人の数は結構多いようです。ちなみにAWBで節追加作業はできますが、これも半分手作業なので労力はそれなりに要します。作業の完全自動化は節の追加位置が自動判定できないので、できないです。自分的にはこのフィルターも含めて、いくつもの方法で案内をつけるのがいいかなと思いました。
1. MediaWiki:Cite error refs without references にヘルプへのリンクをつける。
2. MediaWiki:Cite error refs without references を使って、エラー表示されてる記事を自動で何らかのカテゴリに入れる(これは人力、ボット両方で作業が楽になります。ちなみに標準名前空間とそれ以外のページは別カテゴリにした方が、メンテナンスはしやすいはずです。)。
3.フィルターの注意書き表示で、必要な節の追加をガイドする。
この三段構えがよさそうに思います。上二つについては、別ページで議論すべきものとも思いますが、一応セットになりそうな話なので書きました。--Was a bee 2010年9月24日 (金) 18:58 (UTC)
報告 エラー表示による対策については、MediaWiki‐ノート:Cite error refs without referencesの方で変更を提案いたしました。--Was a bee 2010年9月26日 (日) 12:52 (UTC)
賛成  「スクリプトにするとメンテナンスが大変&整備も大変で、それを簡単に出来るのがこの編集フィルターである、と考えてよいと思います(青子守歌さん 2010年9月24日 (金) 17:12 (UTC) のコメントより)」ということなのですね、フィルターの位置付けがまだよくわかっていませんでした、すみません。私も時々referencesタグを忘れてしまうことがあるので、このフィルターの作成に賛成します。ただ、referencesタグがどうしても理解できない良執筆者がいるかもしれないので、
「1回目:保存できない+警告とreferencesタグの付け方案内」
「2回目:保存できる+Tag付け」
でどうでしょう。Tagとしては
  • Tag:references無し
など。refタグ無しで保存されても、RC上でTagが見えれば、ボットで簡単に拾えるでしょう。--miya 2010年9月26日 (日) 15:04 (UTC)
メンテナンス
Wikipedia-logo-ja.png
  即時削除待ち 347  
  削除依頼 518  
  緊急案件 11  
  特定版削除確認待ち 1  
  保護依頼 8  
  保護編集依頼 2  
  referencesタグがない 0  
  日付のない要出典 32  
  解消済み仮リンク 1,081  
  記事数 927,074  
賛成 MediaWiki:Cite error refs without referencesにヘルプへの誘導を入れて、一月ほど様子を見て来ました。気づいて修正される方、また修正して回られる方もいる反面、referencesを入れずに投稿していく事例もやはり頻繁に発生し続けることも分かりました。統計は取っていませんが、修正を繰り返していく中で見ていた限りでは、少なく見積もってもおよそ一日あたり10件近く発生してると思われます。--Was a bee 2010年11月2日 (火) 09:00 (UTC)
コメント節単位編集を行っている場合に初心者が警告に従った結果、不適切な場所に脚注節が作成される危険性を内包しています。こうした危険性を回避するために発動条件や動作等を調整する必要があると考えます。--Himetv 2011年2月26日 (土) 00:07 (UTC)
コメント 数値を参照して長期的に推移を見ていました(右ボックス参照)。どうも当初(四ヶ月前)は増え続けるだろうと思っていましたが、今のところ全体的に増えもせず減りもせず10件前後を維持したままの状況が続いています。現状修正を行ってくれる方がいるようで、全体の数値は抑えられています。とりあえず現状としてはフィルターなしで何とかなっているようです。--Was a bee 2011年3月23日 (水) 09:46 (UTC)

他言語版からの翻訳時のタイムゾーン誤記入[編集]

提案中 提案中
目的 ドイツ語版・フランス語版などからの翻訳等の際の要約欄におけるタイムゾーン誤記入に対して警告する。
理由 履歴不継承を防ぐため。
  • 要約欄 (summary) に "de:", "fr:", "pl:", "it:", "nl:", "sv:", "no:" のいずれかが含まれていて、
    • "1269738000 <= timestamp < 1288486800" の場合に、上の文字列(de: など)の後に "CET" または "UTC" という文字列が現れるもの。
    • あるいは、"1288486800 <= timestamp < 1301187600" の場合に、上の文字列(de: など)の後に "CEST" または "UTC" という文字列が現れるもの。
  • あるいは、要約欄 (summary) に "ko:" という文字列が含まれていて、その後に "UTC" という文字列が現れるもの。

以上の条件に一致した場合、投稿者に対し確認のメッセージを表示し、問題がなければそのまま投稿させる。

フィルターの文法がよく分かりませんが、このようなフィルターは可能でしょうか。--氷鷺 2010年8月18日 (水) 04:03 (UTC)

timestamp変数の部分の意味が僕には技術的な意味でよく分からないのですが、素朴な疑問として、UTCなりCETなり標準時が記入されてたらそれは履歴的にはむしろOKで、ない方があまり好ましくないのでは。どうでしょうか。--Was a bee 2010年8月18日 (水) 04:23 (UTC)
すみません、説明不足でした。編集日時 (timestamp) で条件を絞ってあるのは「CEST表示の時期なのに、CETと記入してあるもの」や、その逆です(とりあえず来年3月まで)。なお、履歴表示は閲覧時の季節によりますので、今、ドイツ語版の履歴表示を見ると、2009年6月20日(夏)の版も、2009年12月20日(冬)の版も「夏時間」で表示されます。
タイムゾーン無記入は、それはそれで問題なのですが、むしろ曖昧な分、適当に UTC とか CET と記入されるよりも安全です。ただ、編集フィルターで適切な案内ができるなら、タイムゾーン「無記入」への対応も考えたほうが良いでしょう。--氷鷺 2010年8月18日 (水) 04:49 (UTC)
ああ、そうか。夏時間とか冬時間というやつですね。これは方針の解釈が絡む問題かと思いますが、しかし日付と「分以下」の時間指定から、版が単一に特定できるなら、基本的には問題ないんじゃないでしょうか。どうなんでしょう。もともとウィキペディアのユーザーは世界中から投稿してますし、時間もウィキの言語版によらず自分の暮らしている時間の設定に変更している利用者が多いでしょう。少しここらへんは色々と周辺の状況も含めた議論がいる所なのかと思います。--Was a bee 2010年8月18日 (水) 05:12 (UTC)
追記:英語版かどっかで見ましたが、IDで指定して引いている例を見ました。そういうやり方であれば難しい時間の問題はないでしょうが、しかしその説明を作るのがまた難しい・・。--Was a bee 2010年8月18日 (水) 05:15 (UTC)
基本的には「被害」が出るような問題ではありませんが、可能性としては(本当にごく僅かですが)削除や秘匿などの対応が「必要」なケースもあり得ます。それに、間違っている方が少なからずいる以上、技術的に可能なら、注意を呼びかけたほうが良いでしょう。(個人的に、5月頃から何人かの会話ページでお知らせしています) ただ、本当に間違っているかどうかをフィルターに判断させることはできませんので、「毎回メッセージを表示させないで欲しい」という希望があった場合に、(ある程度、問題なさそうだと確認のうえ)ホワイトリストに入れたほうが良いかもしれません。
それと、版ID (oldid) による版指定については、そういう提案もあったのですが、特に積極的な賛成意見がありませんでした。版IDが不変かどうか、はっきりしないのがちょっと問題ですね…。ただ、ページ名だって不変ではありませんし、移動元リダイレクトが削除されるようなことが平然と行われている以上、版IDだけでも、現状よりよほどマシな気がしますが……。ちなみに、個人的には日時と版IDを併用しています。(話題から脱線しているのでもう止めましょうか)
あと、Wikipedia:各言語版の標準時というものを作ってありますので参考にどうぞ。--氷鷺 2010年8月18日 (水) 08:44 (UTC)

コメント timestampによる制限をなくして、もう少し単純に「deやfrなどへのリンクがある場合に、タイムゾーンに関する警告(というか、単純な通知)を出す」というのはどうでしょうか。これなら、例えばUTCでない(日本語版の標準時と同じでない)ウィキすべてに、このフィルター1つで対応することができるかと思います。--青子守歌会話/履歴 2010年9月17日 (金) 21:07 (UTC)

それでも良さそうですね。ソースの文法がまだよく分かりませんが、こんな感じで良いでしょうか?
/* 編集操作で */
(action == "edit")

/* 要約欄に非UTC言語版への言及を含む */
& (summary regex "(de:|ドイツ語版|独語版|fr:|フランス語版|仏語版|it:|イタリア語版|nl:|オランダ語版|ko:|朝鮮語版|韓国語版)")
(要約欄のデータがどういう扱いなのかよく分かりませんでしたが、記入時の(wikiのソースの)形で利用できるという前提で書いてみました)--氷鷺 2010年10月22日 (金) 22:47 (UTC)

コメント私自身は翻訳の際のタイムスタンプには履歴部分をコピーペーストするので(例:カメルーン火山列の場合……en:Cameroon line(20:13, 30 March 2010)、fr:Ligne du Cameroun(8 juin 2010 à 17:55)から抄訳・加筆。) 影響はないのですが、(fr:Ligne du Cameroun(8 juin 2010 à 17:55(CEST))en:Cameroon line(20:13, 30 March 2010(UTC))から翻訳。)と書いた場合に、frの後にUTCが出るという理由で引っかからないようにできるとよいのではないかと思います。--Himetv 2010年10月18日 (月) 17:03 (UTC)

タイムスタンプには履歴部分をコピーペースト』でもマズイ場合があります。翻訳作業開始と翻訳後の記事投稿が、夏時間/冬時間の切り替えをまたぐ場合です。(……もっとも、これも大抵は容易に推測できるので、本当に「致命的な」ミスとなる可能性はほとんどないのですが) で、そういうケースへの注意も含めて、UTCとかいった記入の有無は考慮しない――上の、青子守歌さんの意見を採用する方向で考えたいと思います。--氷鷺 2010年10月22日 (金) 22:47 (UTC)
賛成 「要約欄に非UTC言語版への言及を含む編集」のフィルターとしての作成に賛成します。ただ、条件はリンクのみでもいい気がしますが、言語名を含めた理由はなにかあるのでしょうか。あと、対処操作は通知のみで良いですか(タグ付けなどは不要?--青子守歌会話/履歴 2010年10月30日 (土) 02:04 (UTC)
コメント 放置してしまってすみません。リンクのみでもかなりカバーできますが、リンクの [[ ]] が抜けていたり、単に「独語版から」などと記入しているケースも(特に、慣れていない方に)見られますので、問題なければそういったものまでカバーできたらと思います。タグ付けも、あったほうがいいです。--氷鷺 2011年3月24日 (木) 10:49 (UTC)

ページの白紙化[編集]

提案中 提案中
目的 あらゆるページ(名前空間を限定しない)の白紙化に対して、そのページの削除を希望しているのかどうか、そしてその場合の手順を示す。
理由 ページが白紙化される理由の大半は、荒らしによるものであるか、あるいはそのページをなんらかの意図をもって削除したいと思っている場合の2種類だあると考えられています。そのうち、後者の場合は、きちんとその手順を示してやることで、その意図の達成をスムーズに行なうことができるようになると考えられます。

--青子守歌会話/履歴 2010年8月16日 (月) 16:56 (UTC)

ここ数日、バンダル・ファイターというソフトをこのリンクの三つ目の設定で動かし続けて日本語版の更新をチェックしていますが(白紙化やページの置換があると「ピコン」と音がなる設定になってます)、白紙化のうち荒らしによる戻さなければいけないものは20-30%程度に思えます(正確な数字は分かりませんが感覚として)。よく目に付く白紙化は
  • 1. 編集回数が数十回、数百回といった人が、botによって貼られた{{welcome}}を消すもの(これは消してOKなもの)
  • 2. 次に個人用のサンドボックス(利用者サブページにあるもの)を、記事の完成とともに白紙化する
この二つが比較的よく目につきます。フィルターのプログラム方法や自由度の範囲が分からないのですが、白紙化を対象に何かを提示するなら、ある程度の条件分岐を入れとかないと、多くの場合で偽陽性になってしまうかな、と思います。--Was a bee 2010年8月16日 (月) 18:59 (UTC)
コメント本人あるいは関係者による白紙化への配慮をお願いします。--Ks aka 98 2010年8月16日 (月) 19:17 (UTC)
コメント判断条件の最後に、'利用者:' + user_name != substr(article_prefixedtext, 0, length(user_name))(利用者ページの無視)の追加が必要になりそうです。--Fumiexcel (会話|履歴|メール) 2010年8月17日 (火) 11:34 (UTC)
コメント 「あらゆるページ」としましたが、記事のみに限定してもいいかもしれません。少なくとも、利用者ページあるいは会話ページは除外しておくのがいいと思います。そして、「本人あるいは関係者による白紙化」についても、同様に「こうこう、こういうようにすれば、きちんと削除されます。あるいは、問題があるとのご指摘なら・・・」というような誘導も可能だと思います。--青子守歌会話/履歴 2010年8月17日 (火) 13:09 (UTC)
コメント 利用者空間と利用者会話空間だけ除けば、おそらくあまり関係のないメッセージを見る機会はないんじゃないかと思います。いくつかの変数を組み合わせて複雑な条件分岐を行えば、より広い場合に対応できると思うのですが、それはあまりシンプルなものにはならなさそうです。利用者および利用者会話空間に関しては、「利用者ページと会話ページについて、本人による編集かどうか」とか、「本人でない場合、編集した人の編集数がいくつか(何らかの正当な意味で人のページを白紙化するのはある程度、経験があってからやるのが普通)」とか、「白紙化以前の会話ページの最初の編集者の編集数とbotフラグの有無」とか、ここらへんの値を組み合わせれば、ほとんどの場合でうまく判定ができると思います。ですがある程度時間をかけて組まないと簡単にはいかないだろうと思います。ちなみにbotやサブアカウントの利用者ページをメインアカウントで編集する人なんかもいるので、そこらへんの配慮も必要だったり、という感じかと思います。--Was a bee 2010年8月18日 (水) 04:40 (UTC)
コメント追加。未作成のノートページに、通りすがりの人(主にIP利用者)が、記事やら何やらについての感想文やよく意味の分からないことや、テスト投稿をしていくことがあります。そしてそれは多くの場合、他の利用者によって白紙化されると思いますが、そこらへんも考えると、ノートを入れると条件分岐があったほうがやはり良いのかもしれません。ノート以外であれば、削除する必要もあるでしょうし、フィルターで判定してガイドを提示しても問題ないのではないでしょうか。--Was a bee 2010年8月18日 (水) 04:54 (UTC)
コメント 編集フィルター#2変更履歴一致記録#ページ(記事)の白紙化として既に作成されてしまっていますので、ご報告とともに、議論拡散防止のため、以降の議論は#ページ(記事)の白紙化で行なうことを提案します。--青子守歌会話/履歴 2010年9月11日 (土) 16:42 (UTC)


試験中のフィルター[編集]

新しいフィルターは、この行の直下に追加してください(新しいフィルターがセクションの一番上になるように)。

大きなサイズの増減[編集]

試験中 試験中
目的 サイズの大きな変更に対して、これを検出し、荒らしやテスト投稿などの確認を行ないやすくする。
理由 荒らしやテスト投稿は、比較的サイズの増減の大きいものが多く、通常、これらは専用のツール(IRCやバンダルファイターなど)を使って対処されていますが、これをフィルターにかけて検出することで、より防止しやすくなると考えられます。
フィルター 編集フィルター#20変更履歴一致記録

--青子守歌会話/履歴 2010年9月25日 (土) 14:54 (UTC)

コメント 目的としてはとりあえず「検出する」ということで、対処操作はタグ付けを想定していますが、警告を入れべきどうか、そして、発動条件も、サイズの閾値をいくつにするか(いくつぐらいがいいのか)、対象の利用者グループはどうするのか(全員か、非自動承認利用者か、投稿回数などで決めるのか)、提案はしていますが、仕様は非常に曖昧です。公開・非公開に関しては、閾値があるので、非公開にすべきという意見と、特に悪意を持った利用者への対応は想定しなくていいから公開で良いという意見があるかと思います。みなさんからのご意見をお待ちしてます。--青子守歌会話/履歴 2010年9月25日 (土) 14:54 (UTC)
コメント ページの分割や統合、大量の加筆などでもこのフィルターにひっかかるのでしょうか。もしそうでしたら問題のない投稿でもフィルターにひっかかったという記録が残りますよね。あと、閾値についてですが、悪意のある利用者ならそれよりわずかに小さいサイズの変更を行いフィルターを回避する可能性があります。あまり小さくしても意味はないでしょうし、まず閾値をいくつにするかが難しいところだと思います。--長月みどり 2010年9月25日 (土) 20:11 (UTC)
コメント もちろん、それらに対しても発動しますので、フィルター記録にはそれらが残ります。が、フィルター記録はあくまで「記録」でしかないので、それがそのまま「何かまずい操作をした」ということとは等価ではありませんから、そこまで気にする必要はないです(もしフィルター記録に残すことすらダメとなった場合、フィルターの作成や修正などの運用効率が大幅に低下し、最悪の場合、機能が形骸化してしまうでしょう)。閾値に関しては難しいところですが、既に動いているツールがいくつぐらいに設定されているのかが参考になるかと思います。公開については、まずとりあえず公開にしておいて、あまりにも悪意を持った利用者の操作が多そうな場合は、非公開にする手もあります。ただし、非公開にしておくと、悪意を持った利用者は「これはどうかな?これはどうかな!?」とやりかねないので、その辺りはよく考慮すべきことかと思います。--青子守歌会話/履歴 2010年9月26日 (日) 02:40 (UTC)
賛成 IRCの#wikipedia-ja-articlesチャンネルでLinky-rcが発する「VANDAL ALERT: -1205 bytes」のような注意をRCで表示させるということであれば、賛成します(IRCクライアントをインストールしていない方もブラウザでご覧いただけます)。フィルターを意識して荒らすようなLTA編集の検出はこのフィルターではあきらめ、初心者のいたずらを検出することを主眼にしたらいいと思います。それ以外の、大量加筆、問題記述の除去、分割や統合、ノートへの長文意見もこのフィルターでピックアップされますが、結果として多くの人が見ることになるのはむしろ歓迎してよいことと考えられます。ただ、検出結果は千差万別で良い編集も含まれるため「警告は入れない」とすべきでしょう。またRC上で誤解を招かないよう「穏当なタグを用いる」のがよいと思います。たとえば・・・
  •  Tag:大きな増減
  •  Tag:大きな加筆  と  Tag:大きな除去
など。閾値は最初、2000ないし3000バイトとしておき、フィルターの稼働状況を見て加減するのがよいと思います。--miya 2010年9月26日 (日) 14:46 (UTC)
コメント 3000バイトはUTF-8日本語で1000文字ぐらいということで、反応しすぎかなという気もします。10k~30kバイトぐらいでもいいのでは。--崎山伸夫 2010年11月11日 (木) 11:57 (UTC)
賛成 警告には根拠がないですが、タグを付けるだけなら問題ないと思います。タグを付けることで、「最近の更新」で検索できるようになれば(オプション・フォームの修正も必要なのでしょうが)、探しやすくなるものもあると思います。閾値についても根拠はありませんが、荒らしなどに惑わされずに、運用しながら増減させることは必要な調整でしょう。--Frozen-mikan 2010年9月26日 (日) 15:07 (UTC)
コメント 閾値について、例えば24時間観測でいいので、どれほどのサイズの増減があるのか、特別:最近の更新から拾って度数分布表などにまとめて、統計をとった方がよいかと思います。--青子守歌会話/履歴 2010年9月27日 (月) 03:02 (UTC)
コメント 増減の「減」の方ですが、提案者自身がこんなこと言うのもなんですが、削除関連や白紙化などへの対応が難しいように思います。何を回避すべきか、考える必要があるのではないでしょうか。--青子守歌会話/履歴 2010年10月1日 (金) 13:40 (UTC)
コメント タグ付けだけなら、削除関連や白紙化でも問題は起きないと思いますし、初版投稿者による白紙化がタグで検出されることも有用だと思います。試作してみれば、何を回避すべきかも見えてくるのではないでしょうか。--miya 2010年10月20日 (水) 09:28 (UTC)
コメント 導入や議論などお疲れ様です。別の目的で動かしたbotの副産物でサイズ増減の統計が取れましたのでご報告いたします。2011年02月10日 13:02:01 UTC - 2011年02月12日 13:02:01 UTCの48時間のものです。サイズは1k = 1000バイトです。(利用者:Igitur/加筆・新着記事ダイジェスト#統計としてしばらく毎日自動更新する予定です)
新しい記事のサイズ統計
サイズ 0~ 500~ 1k~ 2k~ 3k~ 4k~ 5k~ 6k~ 7k~ 8k~ 9k~ 10k~
頻度 217 43 156 119 52 28 19 23 12 9 9 29 716


最近の更新のサイズ増減統計
サイズ ~-10k -10k~ -9k~ -8k~ -7k~ -6k~ -5k~ -4k~ -3k~ -2k~ -1k~ -500~ 0~ 500~ 1k~ 2k~ 3k~ 4k~ 5k~ 6k~ 7k~ 8k~ 9k~ 10k~
頻度 12 3 5 10 10 14 13 21 52 154 179 5638 21482 787 447 145 49 30 19 17 15 8 3 26 29139
当初の目的とは違うのかもしれませんが、もし大きな増加をタグで一覧できるようになればWikipedia:最近大幅加筆された記事への報告を促進できるのではないかと期待しております。タグ付けまでならまずは試してみても良いのではないでしょうか。
タグの名称なのですが、サイズが増加しているから加筆とは限らず(除去のリバートや有害物の貼り付けもあります)、減少していても情報源を伴う有意義な加筆や少なくとも整理である場合も少なくないようです。タグにはニュアンスを一切与えず、「大幅なサイズ増加」「大幅なサイズ減少」などとした方が良いように思います。単なるサイズ増減のフラグであれば対応を難しく考える必要もないでしょうし。--Igitur 2011年2月12日 (土) 17:04 (UTC)
コメント データ提供ありがとうございます。実のところ、私自身はすでに増減についてのデータは手元で取得して解析してありました。おおむね同じ傾向が見られます。ただし、この中で果たしてどのあたりが問題のある編集とみなされるのかについて検討がまだなので、提出(コメント)をためらっていました。付与する対処操作としきい値の公開or非公開にもよると思いますので、まずそちらを詰めてから、具体的なしきい値の検討に入った方がよいだろうとも思います。--青子守歌会話/履歴 2011年2月12日 (土) 20:49 (UTC)

対処操作と発動条件[編集]

あらためて仕切り直しの意味で節を分けます。本フィルターについては、対処操作はタグ付けのみ(通知文もなし)、発動条件(フィルターのしきい値)は非公開で作成することを提案します。タグ名は、フィルター名と同様「大幅なサイズの増減」を提案します。--青子守歌会話/履歴 2011年2月12日 (土) 20:49 (UTC)

賛成 その条件にて、改めて賛成表明します。--miya 2011年2月27日 (日) 14:05 (UTC)

長いこと反対意見は出ていませんし、明日あたりにこの条件で作成します。そして、1週間後、問題がなければタグ付けを行ないます。--青子守歌会話/履歴 2011年2月27日 (日) 15:15 (UTC)

報告 編集フィルター#20変更履歴一致記録で作成しました。--青子守歌会話/履歴 2011年2月28日 (月) 21:55 (UTC)
報告 フィルター#20の第204版差分)で、サイズの大幅な増減タグタグが付与された最近の変更を付ける対処操作を付与しました。--青子守歌会話/履歴 2011年3月11日 (金) 00:35 (UTC)
(コメント)新規記事にもこのタグが付けられていますが、個人的には新規記事という目印があれば十分だと思います。 kyube 2011年3月14日 (月) 03:10 (UTC)
(コメント) kyubeさんの意見に同じく。先日私が新規作成した記事(30KB越え)に対して発動しましたが、
  1. 翻訳記事であればこのクラスのサイズはありがち
  2. 私の参加した頃とは異なり最近は新規記事に対する監視の目はそれなりに働いているので、タグ付けによって(タグ付けがない状況に比べて)荒らし検出をより効果的にできるかというと疑問
  3. 荒らし検出という目的で且つ新規投稿に限定して考えれば、サイズの小さいもの(1文のみ、など)も(具体的な数字を持っていませんが)結構ありがちかなと推測しており、荒らし検出という目的に沿ったものとならないのではという疑問
といったあたりの理由から総合判断して、荒らし検出という目的を考えれば、新規記事には不要ではないかと思います。--NISYAN 2011年3月22日 (火) 15:50 (UTC)
チェック フィルター#20の第213版差分)で新規作成を除外にしました。--青子守歌会話/履歴 2011年4月5日 (火) 10:11 (UTC)

コメント 気になったことを2つ挙げます。

  1. 利用者ページにもこのフィルターを働かせる必要があるのか
  2. 現在の閾値は適切なのか

皆さんはどう思いますか。 --プログラムノート/履歴/ログ 2012年1月7日 (土) 13:12 (UTC)

議論が止まって久しいですけれど、ここに問いかけがあるのに気が付いたので、1言だけ。私は、利用者ページは対象から外した方がよろしいかと思います。特に、利用者の下書きページのサイズの増減は、監視する必要性を全く感じません。--G-Sounds会話) 2013年8月8日 (木) 18:00 (UTC)
なお、ユーザーページについては自分のページを編集した時だけ発動対象から除外するという処理でもよろしいかと思います。要するに他のユーザーによるイタズラの検出の一助にするための措置です。
ただ、1週間考えてみましたけれども、ユーザーページをこのフィルタで監視しておく意味は、今述べた他のユーザーによるイタズラ検出の一助にすることくらいしか無いように思えます。しかも、他のユーザーによるイタズラの検出には、各ユーザーページの他者による編集を監視するようにすれば良いと思いますので、わざわざこの「大きなサイズの変化」フィルタによる監視は必要ないと考えます。
というわけで、ユーザーページについては「大きなサイズの変化」フィルタの監視対象から外してしまうのが、効率が良いと私は考えます。--G-Sounds会話) 2013年8月15日 (木) 15:15 (UTC)

削除テンプレート剥がし(フィルター#15)[編集]

試験中 試験中
目的 削除依頼テンプレート剥がし(管理者によるものを除く)を検出し、荒らしを防止する
理由 削除依頼の終了は管理者が行うことになっていますが、荒らしやflameの中では一般利用者によるテンプレート剥がしが行われる場合があります。編集フィルターであらかじめ管理者以外のテンプレート剥がしを不許可としておけば、問題が生じなくなると思います。特に、荒らし専門の利用者でない人がヒートアップしてテンプレートを剥がしてしまう場合に対しては、不許可メッセージで削除依頼ページに誘導することで、もしテンプレート剥がしが行われていれば投稿ブロック依頼につながっていたものがなくなるので、有用なのではないかと思います。
フィルター 編集フィルター#15変更履歴一致記録

-- 崎山伸夫 2010年11月11日 (木) 12:23 (UTC)

  • (条件付き賛成)削除依頼タグ誤貼り付け解消など、はがしても問題ない場合もあるため、単純な除去不可のフィルタであればまずはIP利用者・新規利用者(自動承認された利用者は対象外)に限定して運用すべきと判断します。削除依頼ページ未作成・すでにクローズした削除依頼へのリンクの場合に剥がすのが一般ユーザにできるのであれば、削除審議中の依頼タグを管理者以外除去不可にしても問題ないと思います。--S-PAI 2010年11月23日 (火) 11:32 (UTC)
  • (条件付賛成) S-PAIさんと同意見です。削除タグ剥離は深刻な問題ですが、実際に剥がしても問題ないケースにまでフィルターが干渉してしまうのは逆に問題です。とりあえず、自動承認された利用者以外の削除タグ剥離のみに作動させるべきだと思います。--W.CC 2010年12月25日 (土) 06:26 (UTC)
    • 報告 1ヶ月以上放置されていたようなので、とりあえずフィルター15に作成しました。IPユーザーや未承認の利用者がどれくらいの頻度で削除タグの剥離を行っているのかデータが取れれば今後の参考にもなると思います。--W.CC 2010年12月25日 (土) 06:56 (UTC)
  • コメント 他のフィルターにも関わってきますが、記事の作成者もしくは記事主題の関係者(主にBLP関係を想定)による白紙化に対しての配慮が必要なフィルターです。警告やタグ付けだけならともかく、不許可にするのであれば相当の発動条件を組まなければなりません。それと、編集フィルター#15変更履歴一致記録が非公開になってますが、非公開にすべき理由がありません。むしろ「何を除去してはいけないのか」明確にするためにも、公開フィルターとすべきと考えます。--青子守歌会話/履歴 2010年12月25日 (土) 10:05 (UTC)
    • コメント 削除タグを剥がす事が問題なのであって、それ以外の部分については白紙化はこのフィルターでは特に問題としていません。また、どの部分を残せば発動しないかと言う事があるので、非公開であるべきであると考えます。例えば、BLPであっても削除タグは剥がしてはいけないと考えます。--Vigorous actionTalk/History) 2010年12月25日 (土) 10:17 (UTC)
      • コメント 伝わってないようなのでもう少し噛み砕いて説明します。このフィルターに限らず、「除去」を発動条件とするフィルターは、当然、白紙化されても発動します。白紙化への対応については#ページの白紙化などに詳しいのでそちらをご覧下さい。対象としているのがテンプレートの除去というのは分かりますが、単純な編集除去と白紙化では対応が変わるということを念頭においてください。BLP案件について言うと、自分の記事に否定的なことが書かれていて嫌だから消したい(こんな内容ならウィキペディアに載せて欲しくない)と思って、とりあえず白紙化するという場合は少なくありません(よくある、といっても良い)から、それへの十分な配慮は必要です。もっと分かりやすい具体事例で言うなら、白紙化した利用者名が記事主題の人物や企業などであった場合、それを荒らしやイタズラ扱いするわけにはいきませんよね?ということです。また、白紙化に限って言えば、例えば「(別理由で)削除依頼中に、残っている部分に著作権侵害が見つかって、一旦すべて白紙化したい」という場合も、単純な「除去」として扱われてしまいます。以上述べたように。発動条件あるいは通知文どちらでもいいですが、(このフィルターに限らず)「何かの編集除去」を単純な発動条件に組み込むフィルターは、特殊な事例による白紙化などを十分考慮する必要があるので、そこをきちんと対応してくださいというコメントです。--青子守歌会話/履歴 2010年12月25日 (土) 10:39 (UTC)
        • わかってないようなのではっきりいいます。削除タグはたとえ、BLP案件であっても審議中は剥がしてはいけないものです。したがって不許可とするとなっても問題は無いと考えています。剥がしてはいけないと書いてある削除タグを剥がした時点で荒らしと考えても良いと思います。--Vigorous actionTalk/History) 2010年12月25日 (土) 10:49 (UTC)
        • コメント 同感です。どんな状況であっても、削除タグ剥離を許容するべきではないでしょう。ただ、そういうことを考慮して、警告文にその旨を記載することは必要だと思います。また、Vigorous actionさんも指摘されていますが、荒らし対策という性質上、抜け穴を作らないようにするためにフィルターを非公開にしておくべきでしょう。--W.CC 2010年12月25日 (土) 12:04 (UTC)
          • コメント ええと、誤解されると困るんですが、「削除依頼テンプレートの除去を許容すべき」とは一言も言っていませんし、そう主張する気はありません。ただ単純に「荒しである」と切って捨ててよい場合とそうでない場合があって、BLP関連などでは特にそういうことに対して十分な特別な配慮が必要なので(自分が嫌な思いしてるのにさらに「お前荒らしだ!」なんて言われたら・・・って言わなくてもお分かりですよね??)、そこをお願いしますね、ということです。とりあえずこの件はこれで。--青子守歌会話/履歴 2010年12月25日 (土) 13:26 (UTC)

公開か非公開か[編集]

一応、節を分けます。 まず手続き論的な話として、本フィルターを非公開で作成することへの合意があったとは思えませんし、現在稼働中のほとんどのフィルターが公開であることを考えれば「雪球的に」というのも苦しいでしょう。この点のみをもって公開すべきとは言いませんが、しかし非公開で作成するなら非公開にすることを最初から提案して、みんな非公開でも良いという認識を持っている確証を得てから作成していただくよう強く希望します。 そして本題ですが、「荒らし対策だから」という短絡的な理由での非公開設定には強く反対します。非公開にする本当の理由は、「フィルターの発動条件を調べられてそれを回避されること」を防ぐことであることをまず確認してください。そしてこのフィルターは「非自動承認利用者による削除依頼テンプレートの除去」と最初から明言されていて、それを表す発動条件式の何を隠す必要があるんでしょうか。何を知られたらこのフィルターを回避されるんでしょうか?非自動承認利用者かどうかは見たら分かりますし、対象となる削除依頼テンプレートも公開されているものです。フィルターの詳細は原則として公開されるべきという意見もある以上、少なくともフィルター運用の透明性を落としてまで非公開にすべき明確な理由がないのであれば、公開すべきです。非公開での説明が必要だと思われるなら、個別に私に連絡してください。--青子守歌会話/履歴 2010年12月25日 (土) 13:26 (UTC)

公開すべきだと考えます。同じ荒らし対策の意味合いのある編集フィルター#2変更履歴一致記録の「ページの白紙化」も公開されていますし、青子守歌さんがおっしゃっているように発動条件も想像できるものだからです。
あと、フィルターには自動でひっかかりますが、その内容を判断するのは人間です。「削除依頼テンプレートの除去=荒らし」という機械的な判断をしなければよいのではないでしょうか。--長月みどり 2010年12月26日 (日) 19:04 (UTC)
コメント フィルターを非公開で作成した者です。今回フィルターを非公開にしたのは、青子守歌さんのご指摘のとおり、「フィルターの発動条件を調べられてそれを回避されること」を防ぐためです。しかしながら今回はテンプレート剥がし回避という発動条件がとても分かりやすく、フィルター回避もされにくいことも確かです。そのことについては承知しておりましたが、念には念を入れて非公開としました。というのも、公開状態で作成されたフィルターを後から「発動条件を調べられてそれを回避される」という合意がなされて、後出しで非公開にするよりも、非公開状態から「これは回避されにくいから問題ない」という合意がなされて公開された方が安全性がより高いと判断したからです。今回のようなケースでは非公開にした私が自発的に追認と議論を求めるべきでした。この場を借りて不手際をお詫びいたします。すいませんでした。
1週間待って異論がなければ非公開状態を解除します。--W.CC 2010年12月29日 (水) 11:09 (UTC)
反対 当該フィルターは、SUBSTされた{{Sakujo}}の極一部の文字列に反応するようになっているため、その部分がどこかが判るとその部分を残し、かつテンプレートとして用をなさない形にされる事も十分考えられます。したがって非公開のままにしておくかフィルターの改良が必要であると考えます。--Vigorous actionTalk/History) 2010年12月30日 (木) 05:36 (UTC)
コメント 編集フィルター#15変更履歴一致記録の発動条件は、現時点ではVigorous actionさんのおっしゃってる内容と現在のフィルターの内容が一致していません。そもそも「ごく一部の文字列のみに反応する」という発動条件に疑問も残ります。発動条件について、(公開か非公開か)を含めて、もう一度きちんと議論すべきであると考えます(議論がまとまらないままでの対処操作の付与には反対します。--青子守歌会話/履歴 2011年2月12日 (土) 20:38 (UTC)

名称について[編集]

議論が止まっているようなので、活性化がてら。

このフィルターの名称ですが、他のフィルターと比べてみると「防止」という対処操作に関する名称であって、少々違和感を覚えます。また、「削除テンプレート」という名称についても、本来は「削除依頼テンプレート」であって、ともすると即時削除系のテンプレートまで含まれているような印象を受けます。 というようなことを考慮して、フィルター(およびこの先タグ付け対処操作を付与するならタグの)名を削除依頼テンプレートの除去へ変更することを提案します。--青子守歌会話/履歴 2011年2月28日 (月) 22:07 (UTC)

賛成 提案に賛成します。どこかでフィルター名称のつけ方の統一を図ったほうがいいかもしれませんね。--W.CC 2011年5月29日 (日) 10:15 (UTC)

報告 賛成のみでしたので、フィルター#15の第242版差分)で名称を提案したものへ変更しました。--青子守歌会話/履歴 2011年9月12日 (月) 13:57 (UTC)

ページ(記事)の白紙化(フィルター#2)[編集]

試験中 試験中
目的 ページの白紙化が行われた時、編集が不適切であるという警告を出す。
理由 なぜ白紙化を行うのかを問い、記事の内容に問題がある場合はノートなどを使った問題提起を促す。
フィルター 編集フィルター#2変更履歴一致記録
コメント 導入後試しに作ったフィルターです。目的としては上記#ページの白紙化と同じですが、流れを見て作ったわけではなく、単純に動作サンプルを兼ねてen:Special:AbuseFilter/3を参考に作成したものです。現在はフィルタの対象を記事名前空間に限定しておりますが、上記の議論にもある通りノートなどにもう少し対象を広げていいのかもしれません。--Marine-Blue [ 会話 履歴 電信 ] 2010年9月9日 (木) 13:47 (UTC)
反対 先の#ページの白紙化にもあるように、仕様(記事に限定するのか、ほかの名前空間にも拡大するのかなど)についてもう少し固めた方がよく、現時点で本格運用は早い気がします。また、「白紙化」と言っているのに、発動条件が「サイズが50以下」になっている点についても気になります。発動条件をそのように設定した理由(ただ英語版を真似たというだけではない)をご説明願いします。--青子守歌会話/履歴 2010年9月11日 (土) 16:42 (UTC)
コメント 修正もせず放置してしまいましたが、ログにデータを溜めてしまったため問題がはっきり見えましたね。手掛かりは得られても手法はNG…。
妙な閾値設定はページを単純な一文字に置換するような投稿[9]を検出する目的+元からバイト数が小さいページの修正を検出しない目的でしたが、放置のせいもあって誤検出の問題が大きいようですね。テストを敢行するならせめてアフターケアくらいはしっかりやるべきでした。反省。
さて、不始末の事後処理としてログから得られた情報を整理させていただきますと、問題点は以下のような感じでしょうか。
対象をIPユーザーと新規利用者(と参加歴の短い利用者?)に絞り込む
事後処理が必要となる白紙化の投稿者を調べると、IPユーザーや新規利用者だけでなく、アカウント作成から一定期間休眠して活動を開始した方が引っかかっているものもありました。自動承認された利用者に絞らないほうが良いかもしれません。
投稿内容を調べて削除関係のテンプレート貼り付けやリダイレクトなどを除外する
参加歴の長い方が引っかかるケースもありましたが、白紙化の後に更なる処置を行うケースやリダイレクト化が殆どであり、検出して事後処理を行う必要はありませんでした。
対象とする名前空間の見直し
上でも提案されていますし、記事+ノートの白紙化もありました。放置できるものではないと思います。
考え付いた限りの改善提案です。--Marine-Blue [ 会話 履歴 電信 ] 2010年9月30日 (木) 15:21 (UTC)
コメント 改善案というより、放置ログに対する考察、というところでしょうか。個人的に一番問題だと思うのは、先の議論でKsaka98さんが申し上げている通り、特にBLP関係における関係者の白紙化など、推奨はされないが、かと言って特に強く問題視されるわけではない場合の白紙化に対する対応、もしくは、削除関係の置き換えの検出であると思います。もちろん、これは白紙化に限った話ではなく「除去」を対象にするフィルターすべてに言えることですが、この辺りの点がしっかり対応できないのであれば、フィルターの運用は難しいと考えます。--青子守歌会話/履歴 2010年10月1日 (金) 13:37 (UTC)

仕様変更提案[編集]

フィルター#10 参考文献(出典)に関する節がない記事の作成[編集]

編集フィルター#10変更履歴一致記録

関連議論


ノートで以下の点が指摘されていますので、再検討をお願いします。

  • 「出典」などと書かれた空のままの節ばかりの記事が乱造されている(Shigeru23さん)
  • 「特定のキーワードを含むタイトルを持つ節がない記事」をフィルタリングしているだけ(Penn Stationさん)
  • 出典があるにも関わらずタグ付けされる記事がある(Penn Stationさん)
  • 出典がないにもかかわらずタグ付けされない記事もあります(Penn Stationさん)

対処方法としては

(A) 「警告なしのタグ付だけ」にする(「フィルター#1 カテゴリを含まない記事の作成」の見直し 参照)
(B) 警告をもっと穏やかなものに修正する
(C) フィルター#10を廃止する

の3つが考えられると思います。私としては、タグつけだけなら(現在すでに乱造してしまっている人は別として)新たな乱造の元にはならないと考えて、(A)の「警告なしのタグ付だけ」を推します。--miya 2012年2月24日 (金) 00:27 (UTC)

コメント とりあえずとして空の節が作成されることに関しては、フィルター側で空の節の作成を検出して無効にすることも技術的に可能です(実際には、節のすぐ後ろがレベル2見出しや言語間リンクやカテゴリでないことを確認することになるのでしょうが)。取り急ぎコメントのみ。--青子守歌会話/履歴 2012年2月24日 (金) 03:31 (UTC)
出典に関する「節」を検出してどうなるのでしょうか。「節」は出典そのものではないので、その記事が検証可能性を満たすかどうかの指標にはなりえません。また、出典は必ずしも節に格納されているわけではありませんので、偽陽性も偽陰性も大量に発生してしまいます。
その記事が検証可能性を満たすかを判定するには、記事中に出典の書誌情報やURLなどがあるか否かを判定する必要がありますが、出典の形式は多種多様であり、編集フィルターで検出可能なものとはとても思えません。
以上の理由により、私には現在のテンプレートの必要性を見いだせません。もしも現在のテンプレートを活用している方がいらっしゃれば、ご意見を聞きたいです。--Ohgi 2012年2月24日 (金) 04:03 (UTC)
コメント 私は、まずこのフィルターの対処操作を「タグ付けのみ」にするべきだと思います。その理由は、新たな乱造の元になりにくく、新しいページでの監視にタグが役に立つと考えているからです。その結果、
  • 問題がなければその状態のままにする。
  • 空の出典の節が乱造されれば青子守歌さんの案を実行する。
  • それでも問題が発生するならこのフィルターを廃止する。
このようにするのはどうでしょうか。--プログラムノート/履歴/ログ 2012年7月13日 (金) 13:58 (UTC)
報告 警告を無効化し、タグつけだけに戻しました[10]。--miya会話) 2012年7月19日 (木) 02:30 (UTC)

ログ[編集]