Wikipedia‐ノート:即時削除の方針/過去ログ17

他言語版へのリダイレクトの即時削除追加提案

Wikipedia‐ノート:リダイレクト#他言語版へのリダイレクトにおいて、他言語版へのリダイレクト（サミュエル・ボークレインのような例、英語版へソフトリダイレクトになっている）の議論を行ったのですが、今のところデメリットの方が大きいという意見が出ています。現在他言語版へのリダイレクトを禁止する提案をしているところです。ついては、即時削除の方針においても、「リダイレクト1：無意味なリダイレクト」に「リダイレクト1-4 他言語版へのリダイレクト」を追加したく思いますが、いかがでしょうか。--Tam0031（会話） 2015年3月28日 (土) 04:05 (UTC)

コメント 即時削除は管理者の持つ裁量の中でも特に強い権限ですので、プロジェクト全体へ一度告知してはどうでしょうか。--アルトクール(話/歴) 2015年3月28日 (土) 07:45 (UTC)

お知らせページに記載してきました。--Tam0031（会話） 2015年3月28日 (土) 13:10 (UTC)

しばらく待って異論がありませんでしたので、リダイレクト1-4を追加しました。--Tam0031（会話） 2015年4月6日 (月) 15:48 (UTC)

コメント 最近解消済み仮リンクの修正作業をやっているものです。一点質問があります。仮リンクの修正をしていると、あまり適切とは思えないリダイレクト(例としては、対義語の項目に説明があるからと無理やりリダイレクトしているものや、曖昧さ回避ページにアンカー作ってリダイレクトしているものなどです)を見つけることがあります。そういう場合でもリダイレクトの削除要件には合わないと思うので英語版にソフトリダイレクトしていましたが、今後どのように処理すればいいんでしょうか？とりあえずソフトリダイレクト化した上で自分で即時削除依頼出すのがいいのかなと考えていますが、なんか変な気もしますし…。--Mashir43（会話） 2015年4月8日 (水) 01:32 (UTC)

コメント リダイレクトそのものが不適切であるということですよね？日本語版に変更できる転送先がない場合は「関係のない項目へのリダイレクト」としてリダイレクト1-1が適用できると考えられます。判断に迷う場合はリダイレクトの削除依頼へ提出するのが良いと考えられます。（管理者も判断に迷う場合は差し戻すか、自身でリダイレクトの削除依頼へ回すと思われます）--アルトクール(話/歴) 2015年4月8日 (水) 03:57 (UTC)

コメント アルトクールさん、返信ありがとうございました。わかりました。リダイレクト1-1か通常のリダイレクト削除依頼で対応することにします。--Mashir43（会話） 2015年4月8日 (水) 10:25 (UTC)

全般2「投稿テスト」の指す対象

現在の全般2「投稿テスト」は単に「投稿テストと思われるもの」とだけ説明がされていますが、具体的にどのような投稿をテストと見なし即時削除の対象とするのか、さらに詳説する必要を感じます。

英語版では2011年4月よりノートでの合意に基づいて次の一文が挿入されています。

A page created to test editing or other Wikipedia functions.

――（参考訳）編集テストやその他ウィキペディアの機能のテストのために作られたページ

これを受け、日本語版でも「編集テストや機能テストの結果作成されたページ」（一例）というような文言を盛り込み、「投稿テスト」が意味するところを具体化すべきと考えます。

提案に至った理由としては、記事として成立させる意思をもって投稿された（＝投稿テストではない）と思われるごく短い記事に対し「全般2」を理由としてSD貼付がされるケースが散見され、「全般2」の意図が拡大解釈されているおそれがあると感じたからです。このような例では、確かに内容が数行しかなくスタイルマニュアルにも沿っていない、日本語として異質など百科事典的記事に成長する見込みがない場合が多いように感じられるのですが、そういったものを「投稿テスト」として処理する点には疑問が残ります（実際に、調べれば（特筆性に強い疑問が残りましたが）事物の実在が確認された例に行きあたった経験があります）、こういった拡大解釈を避けるためには、やはり現行の英語版のように「投稿テスト」が指す内容を詳説する必要があるのではと考えます。

以上の件、ご意見を賜りたく存じます。よろしくお願いいたします。 --Y.Sanda（会話） 2015年3月28日 (土) 11:18 (UTC)

「Wikipedia:削除依頼/蜜に群がる蟲」に、サブスタブをテスト投稿として即時削除した形跡があるように、「テスト」はどうも拡大解釈されているようです。いま現在、テスト投稿の例として「書けるかな？ 強い強調（太字） 項目名、など」となっており、本来はこれにそって判断して頂くのが良いのですが。即時削除を依頼する側も、対処する管理者の側も、もう少し慎重に考えなければなりませんね。--Bellcricket（会話） 2015年4月7日 (火) 07:18 (UTC)

同感です。私が現役管理者時代によく目撃したものが、「投稿場所間違い」をテスト投稿と見なして削除したケースでした。「○○」と言う記事名で立項すべきところを、誤って「ノート:○○」に投稿しただけで即削除とか。こんなものは明らかに誤った記事名(?)と言う理由で移動して差し上げればそれでよろしい。残ったリダイレクトは誰が見ても不適切なリダイレクトとしてSDではなく編集で白紙化。これで済む話で、管理者権限など要りません。また「体裁不良」と言うだけで、すぐ全般2として即時削除と言う例も多く見たと記憶しています。やはり明らかに方針文書に反しています。体裁不良は編集対応、もしくは削除依頼送りでしょう。「SDを依頼する方もする方」なのは確かですが、より問題なのは、それを通してしまう管理者の方にあります。私は現在詳しくSDをウォッチしている訳ではありませんので、昔と違い原状では全般2が適切に運用されている可能性もございますが、もし相変わらず不適切な運用が見られているのであれば、人手不足は深刻でしょうが、管理者同士の「相互監視」をもって、適切な、方針文書通りの運用がなされる事を切に願います。投稿場所間違いや体裁不良をSDしたいのであれば、新しいSD基準を加えるのが本当の形であり、全般2の凶悪なまでの拡大解釈などはもっての他と考えます。--Hman（会話） 2015年4月7日 (火) 07:50 (UTC)

上のお二方と同じようなことを感じておりました。このたびの Y.Sanda さんによるご提案に賛成します。 --Kanjy（会話） 2015年4月7日 (火) 09:08 (UTC)

提案者が言及されているのはWikipedia:削除依頼/纏中説禅のことだと思いますが、これは宣伝として即時削除されています。これに限らず「何かわけのわからない文字列が書かれている記事」「外国語で書かれた記事」「面白半分で書いた学校のクラスメイトや内輪ネタの記事」「虚偽の事物の記事」「商品・会社・団体の宣伝らしき記事」など、他の即時削除の要件に該当するものを（おそらくは）婉曲的に「テスト」としている例が散見されます。あと「わずかな言葉・文を書き散らしただけの体裁不良の記事で、特筆性もないことは間違いない」という場合に「テスト」とされる例もあるようです。あまり好ましいものではないので提案の文自体はあってもいいとは思いますが、「本来は削除依頼にかけられるべきで、なおかつ削除依頼にかけられれば十中八九削除されるものが、即時削除ではなく削除依頼を経ての削除で処理される」という効果はあっても、「特筆性のあるものが削除されてしまうのを防ぐ」という効果はないでしょう。--Muyo（会話） 2015年4月7日 (火) 12:00 (UTC)

返信 (muyoさん宛) 実はWikipedia:削除依頼/纏中説禅以前にもたびたびこのようなSD貼付事例を見かけておりまして、うーんこういうケースはどうなんだろうと思っていた折にたまたまこの削除依頼が上がったのであのように発言させていただきました。記事自体は特筆性があるようにも思えなかったのですが、中文が読めず検証ができないので迂闊に票を投じずにコメントに留めた次第です。--Y.Sanda（会話） 2015年4月10日 (金) 13:37 (UTC)

コメント （英語版の事情は詳しくわからないのですが）日本語版の場合、標準空間であればWP:CSD#記事1があり、全般2にかからなくても記事としてまったく成立不能なもの（演説、個人的メモなど）はこちらで対応できますから、追記に反対するわけではありませんが、SD理由が切り替わる以上の実質的な効果は見込めないと考えます。--Jkr2255 2015年4月7日 (火) 12:37 (UTC)

全般2の濫用についてはとどのつまり、「誰がどう見ても明らかにテスト投稿としか見なせないもの」のみを全般2として削除すると言う大原則が、管理者やSD要請者(もっとも彼らは慣れている方ばかりではありませんから、ある程度はやむを得ません。管理者こそが問題です)の中で崩れている点にあると思います。今後もぽつぽつと新人管理者さんが増えていくという点も踏まえますと、今回もしくは今後の酷似のケースについてのみの効果の是非についてよりは、全般2についての一部管理者の独走または思い違いを是正する、もしくは未然に防ぐ事の方が、より重要なことであると考えます。もとより、多少の体裁不良などは記事1の対象外でもありますが(ま、程度問題ですね)。結局のところ、いくら「管理者は特別で無い」と言ってみても、管理者が率先して無茶をやっているようでは、どうにもいけません。それを防ぐためには、最終的にどのような文面に落ち着くかはともかく、文面の改訂については前向きに検討されて然るべきでは無いかと思料致します。私が述べた様なケースでの全般2での即時削除を明確に禁止する文を盛り込むというのも、一つのアイディアでしょう。--Hman（会話） 2015年4月7日 (火) 13:31 (UTC)

賛成します。効果が無いというご指摘は、本来は削除されるべきではない記事を救済したり、管理に費やす時間を削減したりする効果が無いという点ではその通りだと思います。しかし、対象記事の執筆者のモチベーションを維持し、次回投稿記事の改善を促すためには、削除は正しい理由の下で行わなければならないと考えるので、その点において賛成します。--ZCU（会話） 2015年4月7日 (火) 12:59 (UTC)

ご意見ありがとうございます。今回の提案は、「テスト投稿」が拡大解釈されていることで、2008年に即時削除の方針から削除された（参考：当時の合意形成）「非常に短い記事」が実質復活してしまっているのではないかという懸念を覚えたからです。「非常に短い記事」が方針から一度削除されたという経緯がある以上、「非常に短い記事」を対象に含めるような「テスト投稿」の拡大解釈は避けられるべきでは、と感じて書き込ませていただいたものです。muyoさん、Jkr2255さんがご指摘のように、特筆性のある記事の削除を防いだりもしくは記事の成長を促したりする効果は恐らく期待できないとは感じています。

現在は明らかにテスト投稿でない対象は管理者の方がテンプレートを外してくださっているようですが、方針が明確化されれば拡大解釈によるテンプレート付与そのものが抑えられるのではと考えています。ただ私は管理者としてのメンテナンスは経験したことがなく、方針をあまり厳密にしすぎると管理者の方々への負担がどれほど増えてしまうのか見当がつかないので、その点も管理者の方のご意見を仰ぎたく存じます。 --Y.Sanda（会話） 2015年4月10日 (金) 13:37 (UTC)

全般6が適用されないコピーアンドペースト案件

Wikipedia:削除依頼/そこまで言って委員会NPという削除依頼が出ているのですが、番組名がたかじんのそこまで言って委員会から変更されるということでリダイレクトになっていたそこまで言って委員会NP改名されたのですが、コピーアンドペーストでの改名だったので全般6で即時削除依頼したのですが、他者に剥がされて今回の削除依頼が提出されました。私は即時削除票を投じたのですが、このような意見も出されました。現行の即時削除方針にもWikipedia:移動依頼でも初版がリダイレクトだと即時削除できないとは取れないのですがどうなのでしょうか？--K-iczn（会話） 2015年5月1日 (金) 13:09 (UTC)

コメント Wikipedia:削除依頼/そこまで言って委員会NPの対処をご覧ください。--LearningBox（会話） 2015年5月1日 (金) 14:41 (UTC)

ありがとうございます。かなり前に改定されていたんですね。--K-iczn（会話） 2015年5月1日 (金) 15:26 (UTC)

名前空間間違いについて

記事名を移動するときに利用者サンドボックスや通常名前空間などから「Wikipedia」名前空間に誤って移動する例が複数あり、通常名前空間に移動しなおしてリダイレクトになった跡地に{{即時削除|リダイレクト1-2|名前空間が間違っている}}というふうに単純な書き誤りとして即時削除依頼するのですが「リダイレクトの削除依頼を通して下さい」と即時削除タグを剥がす管理者がいますが履歴からして誤って移動したと見なせる場合でも即時削除するべきではないでしょうか？--K-iczn（会話） 2015年5月2日 (土) 03:29 (UTC)

• 提案 名前空間だけ別ボックスになったこともあってか空間間違えの移動もちらほら見られますので、「名前空間を誤って移動した残骸」については、（1-2の類型に挙げるか別に立てるかはともかくとして）正式にSD対象としてしまっていいのではないかと考えます。--Jkr2255 2015年5月23日 (土) 13:04 (UTC)

リダイレクト5の再改定提案

こんばんは、Jkr2255です。3年ほど前に、Wikipedia‐ノート:即時削除の方針/過去ログ14#ノートリダイレクトや括弧つきリダイレクトの即時削除の再考からWikipedia‐ノート:ページの改名#移動に伴って作成されたノートページのリダイレクトについてにあるような議論の結果、WP:CSD#リダイレクト5に「改名提案で削除への合意があること」という条件が付け加えられました。

しかるに、現状のWP:RFDを見ると、改名提案時の削除合意がないリダイレクトが流れてきて、ほとんど反対意見が付くこともないまま削除されているのが現状です。結局こうなってしまうのであれば、わざわざRFDに回付する手間が無駄なのではないかと考えます。

そこで、WP:CSD#リダイレクト5の適用条件として、現状と反対に改名提案の中で残すべきとする意見がない場合とすることを提案します。なお、

• 「合意」とせずに「意見」としたのは、リダイレクトを残すか残さないかの議論が紛糾して改名提案に影響する、という本末転倒な事態を避けるためです。
• もちろん、リダイレクトでない形に書き換えた場合は現状同様、リダイレクトとしての即時削除はできません。

この案について、意見をお願いいたします。--Jkr2255 2015年5月23日 (土) 13:32 (UTC)

• コメント 個人的には「ノートページのリダイレクトを削除することは、機械的に処理できる情報の欠落が発生することや削除に伴う人的資源の無駄なのですべきではない」と思っています。が、削除を依頼するのも削除票を入れるのも削除するのも私は当事者ではないのですし、それらを行う人から何ら問題点が指摘されていなので既にどうでもよいことです。まあ、リダイレクトの削除において、何年も続いている無駄な慣例を維持し続ける人的資源が有るならば、より省エネな方針に変わることも必然だとは思います。--Frozen-mikan（会話） 2015年5月23日 (土) 14:05 (UTC)

• 概ね 賛成 改名提案時にWP:CSD#リダイレクト5適用の合意を取り忘れて、リダイレクトの削除依頼に付されるケースも少なくないため、そういう意味では現実的には提案者の仰るような改訂があったも良いと思いました。リダイレクトの削除依頼に付される他の案件にリソースを割けると思います。なお、提案文にございます「リダイレクトを残すか残さないかの議論が紛糾して改名提案に影響する、という本末転倒な事態を避ける」という観点ですが、そのような場合には先行して改名し、リダイレクトの扱いを改名提案の場で継続とし、そこで合意が得られれば、WP:CSD#リダイレクト5適用可能としても良いと思います。残すべき意見を出したからといっても、合理性のない、単に残すべきと言う意見だけの場合、それのみをもってWP:CSD#リダイレクト5適用不能というのもどうかと思います（明確な理由なくして、単に残したいというのが通るとも思えないので）。--Don-hide（会話） 2015年5月30日 (土) 14:55 (UTC)
• 反対 ノートリダイレクトは本来消す必要がないものです。ページの改名を行う際に要約欄に議論箇所を明示しますが、議論箇所は該当記事のノートであることが多く、記事と一緒に移動されるのが通常の運用です。ノートリダイレクトが削除されると、要約欄のリンクから議論箇所にとぶことができなくなり、閲覧者に不自由が発生します。現状とおり、あくまでもノートリダイレクトを削除することが合意されたとき（事前の改名議論にしろ、事後のリダイレクトの削除依頼にしろ）のみ、削除される運用の方が望ましいと思います。 --JungleCrow（会話） 2015年7月4日 (土) 09:01 (UTC)

プライバシー侵害案件

使用しましたのでよろしくお願いします。--126.62.59.54 2015年5月25日 (月) 18:31 (UTC)

全般8の適用範囲について

こちらでの議論はWikipedia‐ノート:即時削除の方針/全般8のファイル名前空間への適用に移動されています。--2023年9月7日 (木) 07:37 (UTC)

不適切なリダイレクト2-4の適用をテンプレート側で弾くようにしました

ここ最近、WP:CSD#リダイレクト2-4の対象外（基本多言語面の範囲内の文字）にも関わらず、ただ「機種依存文字だ」と言うだけで即時削除を適用しようとしたり、更には削除さえしてしまっていることが多発していたので、テンプレート側でエラーになるようにしました（差分）のでお知らせします。ある程度は試験しましたが、もちろん確実にすべての場合で試験できているわけではありませんので、もし誤り等見つけた方は、報告もしくは自分で修正できる場合は修正をお願いします。--青子守歌（会話/履歴） 2015年10月11日 (日) 11:34 (UTC)

削除者の役割の明記（追加）

即時削除に関しては、削除者は管理者と同じ立場にあります。当方針文書でもほとんど手当て済みなのですが、次の 2 点の「管理者」を「管理者・削除者」に変更するよう提案します。

• #サンドボックス 「管理者が必要と判断した場合には」サンドボックスは取り下げます（Kurihaya 2月1日）サンドボックス部分も改めて俎上にのせます--Kurihaya（会話） 2016年2月19日 (金) 10:54 (UTC)
• #注意事項 「そのような場合に採用できる対処として、削除をした管理者や、」

形式的な追加手当と捉えており、急ぐものではありません。よろしくご検討ください。

なお、本提案の告知の際に、#注意事項の「ユーザー」、「ユーザーページ」を、それぞれ「利用者」、「利用者の会話ページ」に改めていますので申し添えます。--Kurihaya（会話） 2016年2月1日 (月) 08:58 (UTC)

• 賛成 良いと思います。--Damena（会話） 2016年2月1日 (月) 08:59 (UTC)
• サンドボックスを削除した場合、移動保護が外れてしまい削除者には再作成時に移動保護の設定ができません。なのでサンドボックスの削除の文面には削除者を入れなかったような記憶があります。--Vigorous action （Ｔａｌｋ/History） 2016年2月1日 (月) 09:12 (UTC)
  • 移動保護の件、すっかり失念していました。ご指摘ありがとうございます。サンドボックスは提案から除くことにします。--Kurihaya（会話） 2016年2月1日 (月) 09:22 (UTC)
    • サンドボックスへの対処の件、私のようなうかつな者が間抜けなことを言い出さないように、一言追記しておきましょうか。削除者の方は自らの権限をよくお分かりでしょうから誤対処の懸念はあまりありませんけれど。#サンドボックス の末尾に以下の一文を追加することを考えています。

なお、サンドボックスは常に移動保護されるため、基本的に削除者ではなく管理者が対処します。

「基本的に」は、よほど放置しがたい際には版指定削除もあるかな、というだけです。表現は特にこだわるものではありません。--Kurihaya（会話） 2016年2月4日 (木) 10:13 (UTC)

移動保護を何とか出来ないかと考えてみました。

削除後に管理者が移動保護した版のみを復帰。

• 以前の挙動と同じく一度削除してしまうと保護関係はかけ直さないと効力はなかった。(テスト環境はMediaWiki 1.27.0-wmf.12 (9add15b)、書き込み時点の日本語版のversionは1.27.0-wmf.10 (6df51d8))

サンドボックスを移動保護するのではなく、 {{サンドボックスの冒頭案内文}}をカスケード保護で移動保護し、編集フィルターで除去を禁止する。

• ? 技術的には可能そうだが未検証。特定のページを対象とするフィルターのため編集フィルター作成時に反対されそう。

といった状況でした。

また、削除者にもサンドボックスの削除を認める(個人情報の除去など高い法的リスクが存在するような場合に限りといった条件付きでもいい)。削除者が削除を行った場合は再作成後速やかに保護依頼かサンドボックスの初期化依頼のような適切な場所に報告し、移動保護を依頼する。といった手法でもよいのではないでしょうか？--Vigorous action （Ｔａｌｋ/History） 2016年2月4日 (木) 12:38 (UTC)(下線部を追記--Vigorous action （Ｔａｌｋ/History） 2016年2月4日 (木) 15:04 (UTC))

少し気になったのでコメントします。移動保護を再設定しなくともMediaWiki:Titleblacklistに<moveonly>で追加すれば事実上の移動保護のような形になるのではないでしょうか。ただし、インターフェース編集者もその辺はいじれるので本当の意味で「管理者だけに許可」とはならないかもしれませんが。--Infinite0694（会話） 2016年2月4日 (木) 17:22 (UTC)

サンドボックスは偶に貝塚送りってしないといけないんで、個人的には削除者に削除を認めるなら移動も認めたいところですね。あと、テストするなら稼働しているプロジェクトではなくテスト環境などで行ってほしいです。--Vigorous action （Ｔａｌｋ/History） 2016年2月7日 (日) 10:45 (UTC)

TitleBlacklist では不可能です。TitleBlacklist(TB) の <moveonly> は移動先の条件であって、移動元の規制はかけれません。つまり、TB に "Wikipedia:サンドボックス <moveonly|errmsg=MSG>" としても、「Wikipedia:サンドボックス」を別のページへ移動することは可能であり、別のページを「Wikipedia:サンドボックス」（存在していないか、移動元ページへのリダイレクト一版だけであったとしても）へ移動することは不可能です。--rxy（会話） 2016年2月7日 (日) 11:53 (UTC)

• その他の手法による実質的な移動保護の検討は、簡単に結論を得られるものではなさそうですね。それはそれとして、#サンドボックス の末尾への暫定的な追記修正案をあげておきます。

なお、サンドボックスは常に移動保護されるため、削除者が対処する場合は、版指定削除を用いるか、あるいは、削除、再生成後に速やかに移動保護を依頼してください。

この前段の「必要と判断」する主体を、「管理者・削除者」にできるような表現として考えました。移動依頼先を指定するほどでもないかと思いましたが、保護依頼かサンドボックスの初期化依頼のどちらかにでもしておくべきでしょうか。--Kurihaya（会話） 2016年2月19日 (金) 10:54 (UTC)

• （報告）サンドボックスの移動保護にかかる技術的検討は未了ですが、とりあえず方針文の編集を行いました。--Kurihaya（会話） 2016年3月1日 (火) 09:24 (UTC)

明らかに新たに使用される見込みのない日付別メンテナンス用カテゴリ

Category:ライセンス不明の画像 - 2015年12月やCategory:出典不明の画像 - 2015年12月やCategory:未使用のカテゴリ (ウィキペディアのメンテナンス)以下など、メンテナンス用カテゴリで、明らかに新たにページが追加される見込みのない日付別カテゴリについて、カテゴリ7に追加することを提案します。

カテゴリ7

ウィキペディアのメンテナンス用の日付別カテゴリのうち、明らかに新たにページが追加される見込みのないもの

例えば、Category:ライセンス不明の画像やCategory:Wikifyが必要な項目の下位カテゴリが該当します。

使用方法：{{即時削除|カテゴリ7}}

積極的にこのようなメンテナンスに貢献してくださっている方々にわざわざ削除依頼を出してもらって手間を増やす必要ないはずです。 再作成も容易なはずなので、どうしても必要になったら再作成をしていただければよいだろうと思います。--青子守歌（会話/履歴） 2016年2月18日 (木) 13:18 (UTC)

• 賛成します。--ZCU（会話） 2016年2月19日 (金) 02:11 (UTC)
• 賛成 問題ないと思います。--Damena（会話） 2016年2月19日 (金) 08:34 (UTC)
• （賛成）明らかなものであれば、議論の手間を省くべきでしょう。--Kurihaya（会話） 2016年2月19日 (金) 10:59 (UTC)
• 賛成 即時削除で問題ないと思いますが一言。メンテナンス用なんだし、categoryページ作成しなくっても良いんじゃない？ページ内容無くてもcategorizeはできますし。ただ階層化出来ないというデメリットはありますけど。--Vigorous action （Ｔａｌｋ/History） 2016年2月19日 (金) 13:05 (UTC)
• 賛成 削除理由は明らかであり、メンテナンスを円滑に行うために有用です。--Frozen-mikan（会話） 2016年2月21日 (日) 02:11 (UTC)
• 反対 Category:ライセンス不明の画像やCategory:Wikifyが必要な項目については、円滑に処理が行われていて月ごとにカテゴリーを分ける必要がないということだと思います。多分、テンプレートで月ごとにカテゴリーを分けるように設定されていると思うので、テンプレートの見直しをするというのが本筋です。Category:未使用のカテゴリ (ウィキペディアのメンテナンス)については「積極的にこのようなメンテナンスに貢献してくださっている方々」にとっては、「削除依頼」をおこなうことは本来のメンテナンス作業に比べてはるかに軽微な作業であり、「方針」を変更してまで軽減してほしいと思うような手間ではないと思います。「積極的にこのようなメンテナンスに貢献してくださっている方々」から「削除依頼」では手間なので「即時削除」にしてほしいというような要望が出ているのであれば、Category:未使用のカテゴリ (ウィキペディアのメンテナンス)についての反対は撤回しますのでリンク等でお示しください。222.230.131.5 2016年2月22日 (月) 23:39 (UTC)状況についてもうすこし調査してからコメントします。222.230.131.5 2016年2月23日 (火) 14:29 (UTC)
  • コメント もし222.230.131.5さんが未来永劫ずっと1人でそのようなメンテナンス作業をしていただけるならもちろん取り下げます。しかし現状、やってくれている人がいて、その人がやりやすい形でやってるんだろうと思います（やりにくいなら変えようとすると思いますから、単純にその対偶）。それならやってもないやる気もない人が外から「日付別にするな」とかグダグダ言う資格はないと思っています。なお、別に藁人形ではなくて、あまり個別案件にしたくはなかったので具体例を挙げなかっただけで、直近でWikipedia:削除依頼/Category:出典・ライセンス不明の画像_-_2015年12月があったので提案したのです。加えて、こういう細かい作業をなされてないようなのでご存じないかもしれませんが、それより以前にも昔から、これらメンテナンス用カテゴリは何度もWP:CSD#全般8（が適用できるときには即時）削除されてきましたよ。--青子守歌（会話/履歴） 2016年2月23日 (火) 10:57 (UTC)
• コメント反対しない。削除せずに放置だと面倒なのですか？--Ks aka 98（会話） 2016年2月23日 (火) 12:01 (UTC)
• 報告および コメント Template:Wikifyおよび「Category:Wikifyが必要な項目・・・」については処理が速やかに進んでいるためというよりも、Template:Wikify/docに書かれているように完全に月ごとにカテゴライズされているわけではないことが多数の該当記事のないカテゴリーができていることの原因のようです。このあたりの事情についてはTemplate:Wikify/dateHandlerのメンテナンスを行っておられる利用者:しまあじさんがよくご存じのように思います。しまあじさんの投稿履歴を見るとTemplate空間で多数の「Template:HOGEHOGE/dateHandler」のメンテナンスを行っておられるので、他のテンプレートについても同様の事情がありそうですが、まだ確認していません。222.230.131.5 2016年2月23日 (火) 14:29 (UTC)
• コメント 御提案に対して反対しません。222.230.131.5 さんから私の会話ページに、コメントの依頼をいただきまして、「説明」の御要望があったのですが、まず取り急ぎ、即時削除対象にするのが妥当かどうかの点について、コメントさせていただきます。通常の削除依頼に出す労力の問題よりも、即時削除対象にできるなら、ある、大きなメリットがあります。不要になったカテゴリを通常の削除依頼に提出し、その合意が得られて削除された場合には、せっかく削除が実施されながら、その削除と同時に、それと同数の、無用な『削除済み告知』のノートページが作製されてしまうのです。即時削除でしたら、そのような無用なノートページが作製されることはありません。御提案に反対いたしません。--しまあじ（会話） 2016年2月25日 (木) 11:19 (UTC)
  • コメント わざわざコメントありがとうございます。お忙しい中お手を煩わせてしまい申し訳ないです（＆いつもメンテナンス作業ありがとうございます）。さて、これで反対されている方は問題の匿名利用者を除けば存在しませんが、念のため現時点からもう168時間待ちます。これ以上なにか積極的反対する理由がある方は、その間にコメントをお願いします。--青子守歌（会話/履歴） 2016年2月28日 (日) 23:50 (UTC)

報告：提案者ではありませんが、賛否の状況や十分な時間経過などから提案の反映に明らかな合意がなされていると判断でき、なおかつ私も賛成することから反映いたしました（Special:Diff/59077580）。青子守歌さんが意図的に反映を保留しているようでしたら差し戻しください。--Yapparina（会話） 2016年3月24日 (木) 13:56 (UTC)

差し戻しがひつようとは今のところ思えないけど、私が「カテゴライズするときにページは必ず作成しなきゃいけないのか」、ks aka 98さんが「削除しなければならないものか」といった質問を投げかけてますがどなたも回答されていないようですが。。。どうなんですかね。そのあたりの検討ってどこでなされていますか？--Vigorous action （Ｔａｌｋ/History） 2016年3月24日 (木) 14:24 (UTC)

前者について。多くのメンテ用月別カテゴリについてはWikipedia:Bot作業依頼/定期作成ページのメンテナンスにラインナップされており、ウィキペディア日本語版では、この手のカテゴリはシステマティックに自動作成・分類するのが慣習になっていると理解しています。カテゴリに代わる良い整理方法があるなら、それはそれで提案してもらっていいと思いますが、私はとくに思いつきません。

後者について。削除しなければならないということはないでしょうが、個人的意見でいえば、全く不要になり保存的価値も特に無いページは、検索、先頭が同じ全ページ、カテゴリページなどでのノイズとなってしまうので放置よりも削除してほしい、というところです。--Yapparina（会話） 2016年3月26日 (土) 09:33 (UTC)

コメント すいません、私生活との兼ね合いですっかり忘れていただけです・・・。代わりに進めていただきありがとうございます。で、「作らなくても良くない？」「放置でも良くない？」というのは、私もその気持ちが理解できないわけではないですが、先にも書いたとおりメンテナンス作業をしてくれている人のやりやすい形にするのが一番良い形なはずなので、現状が作成していて削除しているのですから、それならそれで良くて、メンテナンスをあまりしない外部から文句つけても何にもならないと思います。--青子守歌（会話/履歴） 2016年3月28日 (月) 00:50 (UTC)

コメントえっと。やりやすいようにしてもらえればよいから、「反対しない」としています。削除依頼を出すくらいなら、即時削除でいいと思います。なんで、別にリバートもしないし、そのままにするつもりだったのですが、Vigorous action さんが再度それを論点として引き出したところでのコメントに対しては不満を述べておきます。

個人的な意見を言えば、削除しなくてもいいものは、一切削除しないほうが、手間の面でも透明性の面でも良いのは明らかだと考えますし、それを超えた必要性があるから、合意によって削除対象にするのだと考えています。これはウィキペディアにおける削除をどのようなものと捉えているかという、根本的な部分での考え方に関わるものです。即時削除であっても、誰か管理者が削除するという負担があり、何かに使ったものが閲覧できなくなるということで作業の透明性は落ちるわけです。削除すると削除しないなら削除しないほうが明らかにコストはかからないですよね。

作業の実態までは分からないので、何か面倒があるなら削除でいいし、削除依頼に出すくらいなら即時削除の対象にしたらいいと思うけれども、Category‐ノート:未使用のカテゴリ (ウィキペディアのメンテナンス)を見ても、過去の削除依頼を見ても、理由は「不要だから」であって、残っていると不便であるという指摘はありません。しまあじさんの説明も、削除依頼の負担についての説明はありますが、削除しないことで生じる労力については触れられていません。これまでのように暫定ということで未使用にカテゴライズすることで不便がないのなら、（「未使用」と区別するために）Category:使用済のカテゴリ (ウィキペディアのメンテナンス)とか作って、空になったらそこに突っ込めば作業ノイズにならないし、カテゴリの変更だけで終わりますから、わざわざ削除依頼を出していただく必要もないですし、わざわざ削除することもしなくていいですし、削除済告知をする必要もないです。SDのタグを貼るのと、カテゴリをつけかえるので、それほど労力も変わらないでしょう。作業を負担する管理者権限を持つものとして、ウィキペディアにおける様々な作業をクロスチェックするアクティブな参加者の一人として、ではそれに見合うメンテナンス上のコスト削減てのは、何かあるのか、一瞬でいいから考え直さない？というのが、コメントの趣旨です。それが「文句」であり、「外部」からの意見ということで排除できるものであり、説明することなく方針の書き換えをしても構わないとYapparinaさん、青子守歌さんが考えていらっしゃるということで理解しました。--Ks aka 98（会話） 2016年3月28日 (月) 10:12 (UTC)

Wikipediaでページを削除するというのは最後の手段であって、その他の方法がない場合に用いるものだというのが私がWikipediaに参加しだした2009年当時では管理系の基本だったはずです。そのとき既に管理者であった青子守歌さんはご存知でしょうが現在普通に緊急で版指定削除がなされているような荒らしでさえ、編集対応で処理されていました(現在のように緊急削除する事に異論はないけど、「削除だけで終わらず必要な措置をキチンと講じてるよね？通報とか。それせず削除するだけなら、害悪になるよ」とはおもいますけど)。

WP:CSD#G4に該当するような記述であっても、WP:Nを満たしかつ出典を付けて記述出来るのであれば、SDで対応するのではなく編集で対応するというのが本来であるはずですよね？で同様に考えるなら今回のような場合、「一時的なものなら作成しない」作成しなきゃ機能的に問題があるのなら「削除しないでよい方法を検討する」それでも駄目なら削除するって段階で検討が必要でしょう。で、どうしても削除やむなしなら即時削除でいいよといったながれなんではないですか？そもそも削除ありきってのは前段階すっ飛ばしてるように見えますが。。。--Vigorous action （Ｔａｌｋ/History） 2016年3月28日 (月) 12:40 (UTC)

お二方から異議があったため、本文への反映を撤回しました。私からもKs aka 98さんへ不満を表明しておきます。『 コメント反対しない。削除せずに放置だと面倒なのですか？』というコメントだけで、上記で説明したようなことを察してもらえると考えるのは期待し過ぎかと思います。時間は十分にあったと思います。最初から、率直にその意見やその案を説明していただければと思います。--Yapparina（会話） 2016年3月28日 (月) 13:44 (UTC)　やや感情的だった表現を修正--Yapparina（会話） 2016年3月28日 (月) 14:47 (UTC)

「メンテナンス用なんだし、categoryページ作成しなくっても良いんじゃない？」という問いは早々にあったのですし、撤回はされていますが「円滑に処理が行われていて月ごとにカテゴリーを分ける必要がない」「テンプレートの見直しをするというのが本筋」という意見もあった。ぼくも「削除せずに放置だと面倒なのですか？」と、問いかけであることが分かるように書いた。さっきも書きましたが、残しておくと面倒な可能性はあるし、ぼくは実作業をしていないので、あまり踏み込むつもりはなく、面倒だというのならそれを尊重するけど、まあ、放置でもいいなら放置でものかって気付くキッカケにはなるだろう。さらに複数の問いかけがある状況なら、作成や削除についての答えは、どこかの段階で得られると期待してもよいだろうということで、それ以上書くこともあるまいと思いました。

また詳しくは書かないのだから反対せず、答えが得られていなくとも、おそらく面倒なのだろうと思いリバートせず、Vigorous actionの指摘の後に尻馬にのって何かいうつもりもなかった。今度は、これこれこういう時に面倒なんですよとか、ここで議論してたんですよとか、そういう答えが得られるのだろうな、と期待してました。

単に問いに答えてほしいというだけで、何かを察してほしいとは思ってません。

ところが、そういう答えは得られなかった。なので、最初にコメントを書いた時よりも手間をかけて調べたり考えたりして、Yapparinaさんのコメントに対しては、「カテゴリに代わる良い整理方法があるなら、それはそれで提案してもらっていいと思いますが、」ということなので、整理方法を書きました。それもこれまで行われていたことと大して変わりません。つまり、最初の削除依頼まで、残しておくとメンテナンスが面倒だったのなら、面倒だったということなら、やっぱり即時削除が必要ってことで終了。不要だから削除依頼したけど面倒だったのではないのなら、じゃあ削除しないって選択肢を考えてほしいな、と。「全く不要になり保存的価値も特に無いページは、検索、先頭が同じ全ページ、カテゴリページなどでのノイズとなってしまうので放置よりも削除してほしい」という考えには同意できないので、詳しく書きました。Vigorous actionさんも書いていますが、基本的には削除しないといけないもの、削除しないと混乱するもの以外は削除しない、というのは、多少古くから活動していたり、管理者になっていたりするなら、ある程度共有できている考えだと思いますが、参加者全体で共有されているもの、明確な合意があるものではないでしょう。「メンテナンスしている人にとって、作業上邪魔になるので削除しなければならないのか、それほど邪魔じゃないのか」が争点だと思っていたのだけれど、削除の扱いが争点なら、改めて自分の考えを書く必要があるだろうと思って書きました。なので、Yapparinaさんの3月26日 (土) 09:33 (UTC)のコメントがない段階で書こうとは思いませんでした。--Ks aka 98（会話） 2016年3月28日 (月) 14:59 (UTC)

取り下げ わざわざ長大な労力を割いて議論することではないので、私からの提案（賛成）は取り下げますね。今までどおり放置でも削除依頼でも、Ks aka 98さんやVigorous actionさんやメンテナンスしてくれている方々それぞれ好みの形で続けてもらえれば良いと思います。もしYapparinaさんがこのまま続行されるのであれば反対はしませんが、根本から考え直したりが必要だと言う方がいらっしゃる中で続けても、得るものは少なすぎると思うので、できれば他のもっと有意義なところにチカラを使っていただけると嬉しいです。--青子守歌（会話/履歴） 2016年3月28日 (月) 23:51 (UTC)

「全般5」の廃止を提案します

「全般5 問題があるため過去に削除審議を経て削除された文章や画像と「同一」または「ほぼ同一」で問題点が解消されていないものの再投稿」を廃止することを提案します。理由は、{{即時削除|全般5}}が添付されたときに、比較の対象となる「削除された文章や画像」を管理者以外の利用者が確認することができないため、正当に使用されたものであるか否かを管理者以外の利用者が検証することが困難であり、悪用ないし濫用される可能性があるためです。222.230.131.5 2016年2月22日 (月) 23:12 (UTC)

• 「悪用ないし濫用され」ないよう管理者が確認、判断するのだから、問題ないのでは。その前提で即時削除テンプレートは存在します。--maryaa（会話） 2016年2月22日 (月) 23:31 (UTC)
• 反対 可能性だけで実害が示されていない。廃止に伴うデメリットに関する考察もない。機能している方針を廃止するには理由が不十分。- NEON（会話） 2016年2月23日 (火) 10:33 (UTC)
• 反対 管理者さんは複数いらっしゃって相互監視しているわけです。そりゃ、管理者さんと意見の合わないことはある。しかしそういう利用者に見えないからと信用を裏切るようなことをする方はいないと信じています。その信用の上でなりたっているのでその根底を崩す提案は受け入れられません。管理者以外の利用者が確認することができないからと不正が行われるようなことがおこったならばそれはツールをいじることではなくその管理者の信任を再考するべきことでしょう。--ぱたごん（会話） 2016年2月23日 (火) 13:21 (UTC)
• 反対 特に問題なく運用されていますし、問題があれば「復帰依頼へどうぞ」で済みます。もっとも、表現上の（たとえば著作物の同一性を考える程度の）「同一性」はこの際あまり問題ではなくて、焦点は「以前削除された際の問題が解消されていない」ことのほうなので、文面の改定なら検討の余地はあるかもしれません。実際、「同一またはほぼ同一」かどうかは権限持ちでないと確認できないのは確かですから。--Hisagi（会話） 2016年2月23日 (火) 14:45 (UTC)
• コメント ぱたごんさんは「管理者さんは複数いらっしゃって相互監視しているわけです。」と書いておられます。私にも管理者さんに相互監視をしていただきたいという気持ちはあります。しかし、過去に熱心に管理者業務を行っておられた管理者さんが何人も解任されているということから見ると、相互監視というのはあまりうまく機能していないように思います。そもそも、管理者さんに相互監視をする義務はありませんし、相互監視というようなあまり評価されない業務まで手が回らないというのが正直なところではないかと思いますが、いかがでしょうか。222.230.131.5 2016年2月23日 (火) 15:30 (UTC)
• 反対 連続投稿への対応力が低下するように思えます。管理者への信頼を基にした簡略化ルールは多くあります。処置の妥当性を検証するためには提案の意も分からないではありません。また、審議などへの常時参加者が多ければ、これらのルールは少なくできるかもしれない。ただ、サイトとして除去対象と判断した画像が再投稿された場合、その対応は1週間に渡って見える状態とします…などと誰に説明するのだろうかと。言われる妥当性の検証とは別に、対外的に対応力なしと思われるほうが問題を抱えるように感じます。--toto-tarou（会話） 2016年2月23日 (火) 16:14 (UTC)
• コメント もし全般5での削除に疑問を感じるなら、対処者かもしくは削除版が見れる誰かに「削除されている内容をくれ」と言えば（法的な問題などがないなら）出してくれるはずです。なので「検証が困難」というのは違いますね。--青子守歌（会話/履歴） 2016年2月24日 (水) 02:59 (UTC)
• コメント 222.230.131.5さんのご意見は「相互監視というのはあまりうまく機能していないように思います」「相互監視というようなあまり評価されない業務まで手が回らないというのが正直なところではないかと思いますが」と、どちらも「思います」なんですが、なにか根拠にされているものはあるんでしょうか？管理者の相互監視が機能しているからこそ管理者が辞任/解任もしくはその直前まで及んだ例や、ある管理者の対処などについて他の管理者が会話ページで苦言や意見を述べているのも眼にしますし、他の管理者が裁量でブロック内容の変更や解除すら行っていますよ。--61.86.153.13 2016年2月24日 (水) 06:43 (UTC)

コメント 「相互監視というのはあまりうまく機能していないように思います」については、現状を総合的にどう判断するかということなので、うまくいっていると判断する「根拠」もあればうまくいっていないと判断する「根拠」もあるでしょう。私がうまくいっていないと判断する「根拠」はやはり上にも書いた解任された管理者が何人かいるということですが、もうすこし補足すると、解任された管理者の多くが精力的に管理者業務を行っていて、彼ら/彼女らにより無期限投稿ブロックされた多数の利用者に対して見直しが行われていないことと、彼ら/彼女らの行動を個人責任に終わらせていて残った管理者の間で再発を防止するために真剣に検討した形跡がないことですね。他山の石という言葉もありますし、残された自分たちも解任された管理者と同じ様な行動をしているのではないかという反省があってもいいと思います。まあ、それをしない人がいるから次々と解任されるわけでしょうが。61.86.153.13さんは「相互監視」について、明確な評価を書いておられませんが、言外に「相互監視はうまく機能していると思います」と主張しておられると思います（笑）。「管理者の辞任/解任」は「管理者の相互監視」の成果というよりは、（かなりベテランの）一般ユーザーによる「監視」の成果でしょう。「管理者が裁量でブロック内容の変更や解除していること」については、61.86.153.13さんは「相互監視」ととらえておられるようですが、私の感覚では、IPユーザーを含む一般利用者が行う通常の編集や管理者が行う裁量による投稿ブロックと同様の通常の業務であって、他の管理者をブロックすることにより暴走を制止するぐらいのことをしないと「相互監視」をしたとは言えないと思います（笑）。222.230.131.5 2016年2月24日 (水) 23:00 (UTC)

反対 Wikipedia:即時削除の方針の導入部にあるように、「管理者および削除者はページを見たその場で削除することができます」。222.230.131.5さんのおっしゃるように「管理者同士の相互監視が機能していない」というのであれば、全般5だけでなく、この根本部分に影響する問題だと思いますので、全般5だけ廃止しても問題は解決しない、と考えます。--Jkr2255 2016年2月24日 (水) 23:24 (UTC)

• （コメント）管理者の相互監視が機能しているかどうかを議論するのが目的ではないでしょう。全般5の廃止を提案するなら、それによるメリットとデメリットの比較考察をお示しいただきたい。--Muyo（会話） 2016年2月25日 (木) 03:19 (UTC)
• コメント「問題点が解消されていない」という要件がある以上は、「問題点」=＜削除する理由＞まで合意されている削除依頼案件でなければ、「過去に削除審議を経て削除された」案件として引用できないと思います。
  また、時間がたてばコミュニティの意見が変化（主に、人員の入れ替わり、個人の意見の変化が原因）することもあるだろうし、ケースEで削除された記事が主題とする事物が特筆性を獲得するようなケースもあるので、あまりにも昔の削除依頼案件を引用するのは、避けるべきかと思います。
  以上の点に留意されつつ、運用されるのであれば、「全般5」を削除する必要はないと考えます。--ZCU（会話） 2016年2月25日 (木) 11:44 (UTC)

ファイル6の廃止提案

WP:CSD#ファイル6の廃止を提案します。

• 文面を素直に読めば、たとえばファイルページに「この画像の転載を禁止します」等の記載がある場合を想定しているものと考えられます。しかし、そういった場合は（適当なライセンスタグが貼り付けられているのに転載を禁止する記載があるような矛盾した場合を除いて）ファイル5の適用を検討すべきであって、ファイル5とは別に即時削除の基準を設ける必要性があまり認められないように思います。
• 文面を無理に解釈して、外部サイトからの転載にこの基準が適用される場合があります。
  • しかし、画像の転載はケースB-1によって削除依頼を経て対処されてきた歴史的経緯を鑑みれば、転載にこの基準を適用するのは適当ではないと考えるべきです。また、転載元や画像に著作権表示があることを根拠として適用されることもありますが、著作権表示がなかろうと著作権侵害は発生しうるし、著作権表示があっても受け入れられるファイルも存在しうるので、著作権表示の有無をもって即時削除するかどうかを変えていくのは適当でないと考えます。
  • また、全般9と比べたときに、ファイル6がファイルの転載に限って削除の要件を軽くすることを意図していない以上、画像の転載にも実質的に要件の重い全般9を適用すべきといえます。
  • 経緯としてはWikipedia:削除依頼/ファイル:IMG 2499.JPGという案件があります。
• 直近5000件の削除記録（2016-01-17T16:37:13Zから2016-03-27T17:14:46Z）を確認した結果、ファイル6を明示して削除されているものは11件。以下のとおり、1件を除いて他の削除基準が適用可能であったとみられます。
  • 3295713は削除の意図が不明です。外部サイトからの転載を理由としていないのであれば、全般5と削除理由の選択を誤ったのではないかとも思われます。
  • 3287582、3270971、3268534、3268517、3251581、3247625は、外部サイトからの転載を単独の理由として削除されているようです。そのうち3287582、3268534、3268517、3251581、3247625はライセンスタグの貼り付けがなかったため、一週間経過すればファイル5の適用が可能だったものと思われます。3270971はWikipedia:自著作物の持ち込みの案内がなされるべきだったかもしれません。
  • 3268535、3268513は、転載かつ著作権マークが入っていたことを理由としているようです。どちらかといえば全般9を適用すべきであるといえます。
  • 3243660、3243659は、削除版には即時削除が依頼される際に「フェアユーズでないと利用不可」というコメントが付されていましたが、削除の趣旨が私にはよくわかりません。こちらもライセンスタグの貼り付けなし。

以下にご意見をお寄せください。--Ohgi 2016年3月27日 (日) 18:57 (UTC)

コメント 提案趣旨については同意できるところもあります。が、まず、文面の解釈論を始めるならその文面になった歴史を調べてどういう意味だったのかをちゃんと理解してからにしてくれませんか（熟練利用者に言うセリフでもないと思うんですが「規則の精神は、規則の字義より優先され」ます c.f. WP:SR）。このファイル6は、まだファイルが画像/マルチメディアと呼ばれていた時代に2008年1月頃に追加（差分）されたものです。そして当時の議論を見れば分かる通り、この基準は最初から著作権侵害を想定した（外部サイトからの転載も含めて、いわゆる{{Non free}}が使われるファイルを対象とした）ものであることは明白です。そしてこれまでも実際にそのように運用されてきましたし今もそういう運用のはずです。また、「ファイルページの内容によれば」とついているのは、単にその当時は著作権侵害っぽいものは削除依頼で議論すべきという風潮だったからであって、おっしゃるようなことを想定していたわけではありません。あとこれは流石に覚えてらっしゃると思いますが、全般9は割と最近できた基準であって、その時の議論では「ファイルは6があるけど」と前提にした上での議論でしたので、単に「全般9があるからファイル6は要らないでしょ」というのはちょっと暴論すぎると思います。

さてこれらの議論を踏まえると、私は単なる廃止には消極的です。仮に「明らかな著作権侵害のファイル（外部サイトからの転載を含む）は全般9に含める」ことにしたとしても、著作権侵害ではない場合に対しての考慮が足りません。後者については過去にも何度か対処した例として「自分で撮った写真です。ウィキペディアでは使っていいですが他では使わないでください」といったものが挙げられます。この場合は著作権侵害ではないので全般9の対象外ですし、ライセンス情報がないわけではありません（ウィキペディアが受け入れるかは別）のでファイル5も対象外です。

なので、落とし所を考えると、私からの提案は、

• 著作権侵害は全般9に任せることにする（というのをここであらためて合意形成しておいて、ファイル6にその旨を注記する）
• ファイル6を「自由利用できないライセンスで供与されたもの」に対する基準であることを明確にするよう改定する

といったところかなと思います。--青子守歌（会話/履歴） 2016年3月28日 (月) 00:46 (UTC)

制定経緯については、追ったつもりになっていましたが、完全に把握しきれていなかったようです。申し訳ありません。また、「全般9があるからファイル6は要らないでしょ」というよりも「全般9ができたからファイル6は要らないでしょ」という意図です。また、風潮といっても慣例化している場合は、慣習法のように一定の拘束力を有するものと考えます。

青子守歌さんのご提案を支持しますが、「自由利用できないライセンスで供与されたもの」についてはファイル5に飲み込むというようなことはできないでしょうか。つまり、自由でないライセンスタグが貼り付けられているものに対してもnldまたはnsdに類似するタグを作成して対応する、ということはいかがでしょう。というのは、上記の通り直近5000件の中に「自由利用できないライセンスで供与されたもの」は存在しません。レアケースに対しての基準を維持することには消極的です。--Ohgi 2016年3月28日 (月) 04:36 (UTC)

コメント 素直に読めば、ファイル6は「ファイルの内容」により「著作権法上の理由により自由利用できないことが明らか」を含みますから、転載も含まれると思いますよ。たとえば「オフィシャルブログから」とファイルページに書いてあってCC-BY-SAが付いてるようなものも含まれるでしょうし。

経緯を確認してみると、もともとは「投稿者によって書かれた画像ページの説明によれば、」に限定されていたところ、Wikipedia‐ノート:即時削除の方針/過去ログ11#画像/マルチメディア6の改定提案による[1]で「ファイルの内容」を含ませていますが、ここは明確な合意や議論があったわけではなさそうです。とはいえその後8年間そのままってのは消極的な合意としてもそれなりに強いと思いますから、あまり改定時の意図を重視してもしょうがないところだと思います。

全般9と比べたときに、ファイル6が軽いってことでもないんじゃないかなあ。作られた時期も影響あるけど、全般9は著作物性の問題について共有されてたから明示する方向に向かいましたけど、ファイルだと著作物性はそれほど問題にならないですし、そこは文章と特に画像を想定したその他の著作物との違いが大きい。全般9に吸収するなら、屋外美術についての注記は必要ですし、たとえば保護期間や平面の著作物に正対した写真の創作性について言及しておくとか、修正は必要だと思います。全般9と別建てにしておいたほうがすっきるすると思う。

外部からの転載を全般9に吸収するなら、ファイル6はファイル5に吸収させてもいいと思います。「フリーなライセンス＋フリーでない制限を追記」の場合にどうするかを決めておいた方がいいと思います。CC-BY-SAのテンプレを貼っているけど、ウィキペディア以外での使用を禁止しているとかいう場合に、ライセンス重視で追記を無効扱いするのか、ライセンス誤認とみて削除対象にするのか。

即時削除は基本的に「レアケース」だと思いますよ。--Ks aka 98（会話） 2016年3月28日 (月) 11:23 (UTC)

「フリーなライセンス＋フリーでない制限を追記」すなわち「自分で撮った写真です。ウィキペディアでは使っていいですが他では使わないでください」のような案件については、投稿者に対して説明が必要なので、どちらかといえば即時削除よりも削除依頼で処理する方が適当ではないかと考えるのですが、一概にそうとも言えない面がありそうですので即時削除の対象として残しておくことに反対はしません。

「レアケース」について補足すると、「即時削除は削除依頼で処理されるもののうち、削除すべきことが明確で、よくあるケースに限定して、手間を減らすことを目的に議論を省略して削除できるようにするものである」という前提のもと、「レアケースはそもそも件数が少ないから削除依頼で処理してもそこまで手間がかかるようなものではないし、むしろレアケースほど今まで議論が尽くされてきたとは言いがたいから削除依頼を通すべきではないか」という意見を持っています。ここは色々な意見がありそうなので、「レアケース」であることをもって即時削除の対象から除外すべきだと主張したいわけでもありません。--Ohgi 2016年3月29日 (火) 19:40 (UTC)

ケースEで記事が削除され、カテゴライズが0になったカテゴリ

現在審議期間中のWikipedia:削除依頼/Category:邦道連合を想定しています。邦道連合がWikipedia:削除依頼/神戸山口組の三次団体で削除されたので、リンク元をチェックしたところCategory:邦道連合を発見し、カテゴライズ数が0だったので削除依頼を提出しました。先例としてはWikipedia:削除依頼/Category:英組とWikipedia:削除依頼/Category:真鍋組があります（私が依頼を提出しました。真鍋組、英組ともにWikipedia:削除依頼/特筆性の無い暴力団記事20151028で削除されています）。これらのカテゴリは元々記事数が1しかなかったようですので、おそらく「過剰なカテゴリ」として審議すれば削除になったかと思われます。

これら3カテゴリのように「記事がケースEで削除され、カテゴライズ数が0になったもの」については即時削除で対応されても良いのではないか？　と思うのですが、いかがでしょうか？　--124.108.255.164 2016年4月1日 (金) 15:23 (UTC)

• 反対 カテゴリページからは「過去にカテゴライズされていたかどうか」はわかりません。そのため、使用しなくなったことをWikipedia:削除依頼で示してもらう必要があります。大元の削除依頼と同時提出でも構わないです。即時削除ではそこまで確認が取れない（あるいは「再使用」や「分類変更」で対処される可能性も否定できない）ので条件に加えるべきではありません。--アルトクール（会話） 2016年4月1日 (金) 15:31 (UTC)

全般5の改定提案

少し前に、全般5「問題があるため過去に削除審議を経て削除された文章や画像と「同一」または「ほぼ同一」で問題点が解消されていないものの再投稿」について「管理者以外の利用者が確認できないため」ということで#「全般5」の廃止を提案しますという話がありました。

まぁ、この廃止提案については論外ということで、無事却下されているのですが、実際のところ「内容が同一またはほぼ同一」かどうかは権限持ちでないと確認できないのはまったくその通りですし、全般5が意図するところは（そして実際の運用としては）「以前削除された際の問題が解消されていないこと」であり、仮に文章の同一性がほぼゼロであったとしても「問題点が解消されていない」のであれば全般5で対応できる（している）のだと思います。

そこで、以下の表現修正を提案します。

現行

問題があるため過去に削除審議を経て削除された文章や画像と「同一」または「ほぼ同一」で問題点が解消されていないものの再投稿

改定案

過去に削除審議を経て削除されたページや文章・画像などについて、その削除理由となった問題点が解消されていないものの再投稿

自分でもあまり良い文案とは思いませんが、現行の、文章の同一性を条件とするのはちょっと避けたいと思う次第です。--Hisagi（会話） 2016年4月2日 (土) 14:45 (UTC)

• 賛成 WP:DEL#Eの場合などページの内容が同一またはほぼ同一でなかったとしても削除理由がなくなる訳ではありませんから、同一理由で再度審議する必要は無いと考えます。実際多くの管理者や削除者は提案内容と同様の運用を行っていますが、こういった案件もあります。--Vigorous action （Ｔａｌｋ/History） 2016年4月2日 (土) 16:13 (UTC)
• 賛成 あまりアクティブではありませんが、管理者を務めておりますKubouと申します。

改定案の文章であれば、実際の運用として、タグを貼る方は削除依頼の審議内容と現状の文書をみて問題が改善されていないと判断できることから、削除された版を確認しなくても運用可能であり、改定案に賛成いたします。

私のこれまでの運用は、即時削除については、コミュニティの審議を経ないことから慎重に対応を行っており、字義どおりに捉えた場合にVigorous actionさんが例示したケースと同じように迷い、対処を見送ったケースがそこそこありました(改定案側に倒しての運用は行っていませんでした)。全般5の趣旨としてはHisagiさんがおっしゃるように「問題が解消されていないこと」が言いたい事だと思います。改定案の文書であれば、ケースEであれば、その問題点が解消されていない(=特筆性がない)ですし、ケースB-1であれば、文章が多少改変されても著作権に反するのであれば削除可能という判断になるかと思います(こちらは著作権の判断が少し難しいですが)。--Kubou（会話） 2016年4月3日 (日) 03:48 (UTC)

• 賛成 もとは「一度削除された記事をその削除された記事の作成者が再作成する行為」に対応することが主目的だったのでしょうが、そうすると再作成時に文面をちょっと変えれば「同一でない」と言い張れますし、それ以上に現状では「ケースEで削除された人物の記事を別人が再作成する」というケースが多いので。--Muyo（会話） 2016年4月3日 (日) 04:08 (UTC)

報告 改訂を実施しました(Special:Diff/59286702)。--Hisagi（会話） 2016年4月9日 (土) 15:29 (UTC)

「即時削除」を使用しました

救済措置として、「即時削除」を使用しました--ベアトリス（会話） 2016年4月24日 (日) 01:53 (UTC)

「即時削除」を他の利用者から除去されましたので、お知らせ致します。--ベアトリス（会話） 2016年4月24日 (日) 04:34 (UTC)

コメント 利用者:ベアトリス（会話 / 投稿記録 / 記録）さんが即時削除テンプレートを貼られたページはBOACスチュワーデス殺人事件です（貼ったときの差分）。ただ、明らかに不適切な即時削除テンプレートの使用でしたのですでに剥がされています。--Mirinano（会話） 2016年4月24日 (日) 05:53 (UTC)

モジュールの即時削除

モジュール:Convert/testerに即時削除を貼ってもエラーになります。モジュールでは即時削除はできないのでしょうか？ --にょろん（会話） 2016年4月28日 (木) 20:48 (UTC) 削除できないのでとりあえず利用者ページに移動させました。利用者:にょろん/ゴミ箱/Convert/tester --にょろん（会話） 2016年4月28日 (木) 21:02 (UTC)

ソースコードの記述用空間となっているため、通常のwiki文法が通用しません。元々モジュール名前空間は即時削除の方針を策定した時期には無かった空間で、その削除に関しては方法が指定されていません。そのためWikipedia:管理者伝言板/その他の伝言にモジュールの即時削除を申し出た上で、モジュール上に{{即時削除}}を通常通り置いてください。管理者は管理者伝言板の通知と本文上にある即時削除を確認したうえで削除を行います。--アルトクール（会話） 2016年4月29日 (金) 04:25 (UTC)

わかりました。しかしながら、通常通りにテンプレートを置くとエラーで投稿できないので、コメントとして即時削除のテンプレートを置くことになります。もちろん、いつもの赤い表示もありません。ご容赦ください。--にょろん（会話） 2016年4月30日 (土) 07:51 (UTC)

提案 モジュールだけ技術的理由で即時削除できないのは問題なので、アルトクールさんの方法を正式に表に書くことを提案します。具体的には、冒頭部の第二段落「テンプレートの基本的な利用は…」の後ろに「なお、モジュール名前空間は通常の方法ではテンプレートを貼り付けることができません。そのため、ページには「--{{即時削除|基準番号}}」の形でテンプレートの前に--をつけてコメントアウト状態にして貼り付け、その後Wikipedia:管理者伝言板/その他の伝言に申し出てください。」を追加したいと思います。反対がなければ168時間で変更します。--青子守歌（会話/履歴） 2016年4月30日 (土) 06:59 (UTC)

反対 モジュールに対して安易に既存の即時削除規定を適用するのは意図しない問題を発生させる危険があると判断し、反対します。特に、require で読み込ませているモジュールは、それだけではリンク元には出ません。モジュールにおける「参照読み込み」は、それ自身が直接 invoke で呼ばれているか、require で読み込んでおり、かつその require を使用しているモジュールが invoke で呼ばれた場合のみ、リンク元に反映されます（つまり、直接的であれ、間接的であれ、invoke で読み込まれない限りは「参照読み込み」にはならない）。杞憂かもしれませんが、<onlyinclude>{{#invoke:モジュール名|main|args}}</onlyinclude> のような形でメンテナンステンプレート等の一時的に貼り付けられるテンプレートで使用されている場合、リンク元が空となる事態も想定できます。 この状態で 全般8 を適用すると、使用時にエラーを起こしかねない危険性があります。--rxy（会話） 2016年4月30日 (土) 08:05 (UTC)

例

1. モジュール:foo が require("モジュール:foo/config"); で モジュール:foo/config を読み込み（ モジュール:foo/config のリンク元は他から読み込まれていない限り、この時点では空）
2. メンテナンス用の一時利用テンプレート bar が <onlyinclude>{{#invoke:foo|main|args}}</onlyinclude> で作成される（ モジュール:foo/config のリンク元は他から読み込まれていない限り、この時点では空）
3. bar が貼り付けられる（この時点でやっと モジュール:foo/config は「参照読み込み」としてリンク元に記載されます）
4. bar が貼り付けられた唯一のページが削除されたか、 bar が取り除かれた（モジュール:foo/config のリンク元は他から読み込まれていない限り、この時点において空となる）
5. モジュール:foo/config がリンク元なし、かつ初版作成者のみの投稿であったため、削除される
6. bar が貼り付けられるが モジュール:foo/config は存在しないのでエラーとなる

--rxy（会話） 2016年4月30日 (土) 08:05 (UTC)

コメント それは通常のテンプレートも同じような危険性はあって（それよりは少しだけ危険度は高いかもしれませんが）、モジュールだけ即時削除を禁止するほどの理由にはないと思います。そもそも「内容が有用な場合」は削除されないのですし、有用かどうか（つまり削除したら危ないか）が分からない状態で対処するほど無能な管理者・削除者はいないと思います。加えて、もし削除されたあと問題があるなら復帰させればいいだけですし。--青子守歌（会話/履歴） 2016年4月30日 (土) 08:15 (UTC)

コメント Template名前空間に関してはメタテンプレートでない限り、いきなり問題になることは少ないでしょう（問題が出れば復帰すればいいだけというのもわかります）。モジュール名前空間はメタテンプレートと同じで、複数のテンプレートや他のモジュールに影響を及ぼす可能性もありますし、それなら面倒でも「削除依頼を通す」ことを原則として、WP:CSD#全般8のファイル名前空間と同じように扱う（つまり誤投稿救済）ようにすればいいんじゃないでしょうか。本人依頼による即時削除の場合は削除対応する管理者も投稿者の履歴などを確認して削除するでしょうけど、モジュール名前空間はMediawiki名前空間と同じで「ある程度の知識が無いとその危険性を認識できない」でしょう。青子守歌さんには「当然」かもしれないですが、他の管理者にとっては「当然」ではないかもしれません。今信任されている管理者でもMediawiki名前空間を扱える、モジュール名前空間を扱える管理者は如何ほどいるでしょうか。分からなければ手を出すなでも「即時削除で本人依頼だから削除」をしてしまうおそれがあるなら、管理者側に判定条件を付けるか、即時削除の判断基準を一段階引き上げるか、削除依頼で検証してから削除しても問題ないと思いますが。--アルトクール（会話） 2016年4月30日 (土) 08:29 (UTC)

（編集競合しましたがそのまま）モジュールに対する即時削除を禁止すべきとまでは述べていませんが、現状の規定をそのまま適用するのは危険であると述べているのです（特に全般8）。モジュールはテンプレート以上にリンク元での依存関係調査が困難なことに加え、en などから移入されたものの、使われているのかどうかすらも分からない上、doc も未作成というモジュールが散見される現状では、とても賛成できる状況ではありません。問題のある削除が行われ、問題発覚から復帰までの間に同名のページに別機能を持つモジュールが作成され、それが更に別のモジュール等で使われている　といった状況になった場合、調査や修正が複雑になりかねないと考えます。このことより、モジュール名前空間に対する削除操作は慎重になる必要があると考えます（依存関係の明確化や、使用予定があるのかすらわからないモジュールの移入についても、そろそろ考えないといけないかもしれませんが…）。そもそも、悪戯や荒らしを除いてモジュール名前空間で即時削除を必要とする事例はあまり思い浮かびません。現状ではモジュール名前空間に SD を適用できるメリットよりも不利益になる可能性が高いと判断します。--rxy（会話） 2016年4月30日 (土) 09:06 (UTC)

SD出来るようにする前に、モジュールの作成基準決めた方がいいと思います。その作成基準に/docの作成と使用した場合ノートで使用ページを明記する事などを明文化しておけば依存関係もわかりやすくなり削除したとしても影響がわかるでしょう。

更に原状削除権限を持つ人の中には問題があった場合、即時削除を実施した人に連絡しても裁量削除の範囲内にもかかわらず復帰依頼を出せといった方もおられますから、単純に復帰すればすむといった問題でもないでしょう。

また、履歴継承のミスなどによる即時削除も版指定削除なども有ることから、一定の短期間(72時間程度を想定)を対象とするなど範囲を絞り込む方がいいとおもいます。同一のモジュールであったとしても原状それが同一であるか、などの検証がなされて居ませんから即時削除出来るものには基本入れない方が良いでしょう(明らかなtest「ｂきうれあｃｈ」のようなものとか荒らしだとか、モジュールとして機能しないものは除く)。--Vigorous action （Ｔａｌｋ/History） 2016年4月30日 (土) 14:04 (UTC)

作成基準は決めたほうがいいでしょうね…。よいご提案かと思います。また、ファイルと同様に初版投稿者のみの投稿にかぎって指定時間内の SD 貼り付け（扱い）など、条件付きであれば認めてもよいかと思います。モジュール名前空間での悪戯については、構文として正しくないモジュールはそもそも保存できないはずなので、よほど構文として正しく認識されるが、明らかに使い道のない　とかでない限り、全般 1 - 3 で削除できるようなものにはならない気がします。--rxy（会話） 2016年5月1日 (日) 01:59 (UTC)

コメントrequireで読み込まれている時の影響を懸念されているようですが、そうであれば、「移動」も禁止しないと意味がないのではないかと思います。移動できれば削除と同じくそのモジュールを機能させられなくできるわけですから。テンプレートにおいてもモジュールと同じように間接的に参照しているテンプレートもあります。かなり高度なテンプレートで、実行時に初めて参照先のテンプレート名が決定されるような仕組みになっているテンプレートです。私の意見はテンプレートと同じで即時削除できるようにして良いと思います。あるいは、GFDL関連はほぼ同一の内容のGFDLを満たした別のページ名を用意しておいて即時削除と同時にそのページに(移動させて)置き換えるような仕組みにしてもいいのではないかと？ --にょろん（会話） 2016年4月30日 (土) 16:43 (UTC)

コメント 「移動」なら管理者でなくても即時差し戻しが可能です。「利用者ページサブページに移動させてから即時削除を貼る」ことで即時削除ができるなら、モジュールに詳しくない（私のような）管理者がうっかり即時削除してしまうようなリスクは避けたほうが良いのではないでしょうか？--miya（会話） 2016年4月30日 (土) 21:43 (UTC) インデント修正--rxy（会話） 2016年5月1日 (日) 01:59 (UTC)

モジュール名前空間で作成されたページは、名前空間を跨いだ移動をしてもページの「コンテンツ・モデル」は "Scribunto" （モジュール構文）で固定されますので、通常名前空間に移動しようが、利用者名前空間であろうが、名前空間を問わず「モジュール構文」扱いされますので、即時削除のテンプレートは機能しません。--rxy（会話） 2016年5月1日 (日) 01:59 (UTC)

えっと・・・テンプレートは機能しなくても、記述を「{{即時削除|全般8|理由}}」に置き換えることはできますよね？--miya（会話） 2016年5月1日 (日) 13:17 (UTC)

--{{即時削除|全般8}} のように、Lua のコメント化状態でないと、構文エラーで保存すらシステムが許可しません。もちろん、テンプレートが機能しないということは、Category:即時削除対象のページ にも入りません。ただし、/doc にかけば、普通に動きます。しかし、モジュール名前空間以外に移動させてしまった場合、一切の編集を受け付けなくなるようです(test2wiki: での現時点における確認結果)。--rxy（会話） 2016年5月1日 (日) 13:34 (UTC)

コメント モジュール関係に関しては作成基準や更新基準、機能改廃基準、依存関係の明確化、移動基準その他もろもろ一切決まっていないはずなので、決めたほうがいいですね。荒らしなどによって被害が出るなど、必要であればモジュール名前空間の全ページ移動保護も検討する必要があるかもしれませんが。--rxy（会話） 2016年5月1日 (日) 01:59 (UTC)

rxyさん宛 Wikipedia:井戸端/subj/テンプレート・モジュール作成についてのガイドライン化提案で仰る内容の提案が為されておりますので（削除関係まで踏み込むのかは分かりませんが）お知らせしておきます。--Nami-ja（凪海） （会話 / 履歴） 2016年7月14日 (木) 22:43 (UTC)

利用者:にょろん/common.css の削除

すみません。これも一度削除したいのですが、削除できないですよね？GDFL違反の疑いがあるので一度削除したいんですけど。 --にょろん（会話） 2016年4月30日 (土) 07:45 (UTC)

これもモジュール同様にWikipedia:管理者伝言板/その他の伝言にモジュールの即時削除を申し出ることにします。 --にょろん（会話） 2016年4月30日 (土) 07:48 (UTC)

こちらは、どこかの誰かが削除してくださいました。CSSは別なのでしょうか？ --にょろん（会話） 2016年4月30日 (土) 08:02 (UTC)

「記事1」への文言の追加

解決済み

2016年5月12日 (木) 01:48 (UTC)

先行する議論として「利用者‐会話:山田晴通#方針によらない即時削除はおやめください」をご参照ください。（なおこのやりとりの内容は一定期間後に「利用者‐会話:山田晴通/過去ログ09」へ移動される見込みです。）

「記事1」は、「定義になっていない、あるいは文章になっていないもの」を対象としています。これについては補足として「なお、定義がないということの意味は「『項目名は○○である』という定義文がない」という意味ではありません。冒頭に定型定義文がないことは、即時削除の理由とはなりません。」とあり、定義文がなくても定義になっていると判断される場合があることが示されています。

これに対して、形式的に定義文があっても、「百科事典としての解説に足る定義がないものを WP:CSD#記事1 として削除する運用・慣例があります」というご指摘を上記の議論の中でいただきました。

山田はそれまで、そのような「運用・慣例」の存在を承知しておりませんでした。これは方針文書類にこれが明記されていなかった（少なくとも関係する範囲ではように思われる）ことによっておこったことです。上記のような「運用・慣例」が方針に明記されていない状況が続けば、今後、新たに管理者となる方々が山田と同じ轍を踏む虞れが大きく、それをまた誰かが指摘するといったことが繰り返される可能性があります。

確立されている「運用・慣例」だというだけでなく、現状の文章を読むと、わざわざ定義文がなくても定義になっていると判断される場合があることが示されており、「定義になっていない、あるいは文章になっていないもの」を限定的に捉えようとしているという含意が読み取れます。言わずもがなで、特段の言及がない、（形式的な）定義文のある（しかし内容が百科事典としての解説に足る定義がない）記事については、この条文は適用できないと思い込む誤解（実際、山田はそのように誤解しておりました）は、起きやすいのではないかと思います。

以上を踏まえ、「記事1」の説明の末尾に続けて以下の文言を追加することを提案します。

＜また、定義文があっても百科事典としての解説に足る定義がないものは、対象となります。＞

これは、現在の「運用・慣例」の追認、確認のための加筆であり、反対される場合は、「運用・慣例」をお認めの上で、文言の変更を要しないという趣旨なのか、この「運用・慣例」の存在を否定するという趣旨なのか、あるいは、この「運用・慣例」の存在を認めた上でそれが変更されるべきであるという趣旨なのかを分かりやすくご説明いただくことが望ましいと考えます。なお、提案者としましては、本件について、少なくとも1週間の議論が必要かと考えております。--山田晴通（会話） 2016年5月2日 (月) 18:39 (UTC)

• • コメント方針の大本となった英語版に当たると、No contextにあたるのですが、そちらでは十分なコンテキストを欠く記事に適用されますとあります。これを持ち込むときに定義文と訳したのが解釈に相違がでたのかと思いますので、定義文という書き方そのものを、記事の文意や主題を欠くとするのが相応しい気もします。コンテキストを訳すに、日本語で適切なものが思いつかないのですが、現在ならばコンテキストで通用するかもしれません。個人的には、訳した当時を知っていたものですから、疑問に思っておりませんでしたが、指摘されると確かにと。--Faso（会話） 2016年5月2日 (月) 19:14 (UTC)
    • Fasoさん、コメントありがとうございました。特にご異論がありませんので、文言の追記を実施します。--山田晴通（会話） 2016年5月12日 (木) 01:48 (UTC)

機械翻訳はテスト投稿なのか

機械翻訳記事が即時削除の中に全般2で依頼されていることがあります。5月20日時点ではバップュ・ケネディ、トゥルー・スパーク。しかしテスト投稿とは、書けるかな？ 強い強調（太字） 項目名と例示がなされており、対象は記事にすらなっていないものであるとされます。最近ではWikipedia:削除依頼/境王子が濫造した機械翻訳記事群がありますが、誰もテスト投稿であると主張はありません。方針に合致しないものとして、差し戻して、貼りつけた人に通常の削除依頼を促すべきでしょうか。--多摩に暇人（会話） 2016年5月19日 (木) 23:52 (UTC)

例示されている二つの記事はテンプレを除去しました。全般2で想定されている即時削除対象ではないと考えます。削除依頼をするかどうか、促すかどうかは、多摩に暇人さんが削除されたほうが良い、削除を検討したほうがいいと考えているかどうか次第、でしょうか。--Ks aka 98（会話） 2016年5月20日 (金) 12:56 (UTC)

Ks aka 98さんありがとうございます。即時削除対象でないというお答えありがとうございます。今後即時削除で見かけた場合は、ケースバイケースで対応していきたいと思います。--多摩に暇人（会話） 2016年5月21日 (土) 09:28 (UTC)

Template:即時削除/記事1の修正提案

Wikipedia:コメント依頼/山田晴通 20160521を読んで考えたのですが、こと記事1に限っては「方針上の記事1」（定義になっていない、あるいは文章になっていないもの）とテンプレートの概要（定義なし）の相違が誤った依頼・削除の原因の一つと考えられます。そこでテンプレートの概要を、現在の「定義なし」から「定義あるいは文章になっていないもの」（方針そのままだと長いのでちょっと縮めました）へ修正することを提案します。--Open-box（会話） 2016年5月28日 (土) 14:30 (UTC)

• 貼り付け時や権限行使時に従うのは、テンプレートの文面ではなく方針に該当するかだとおもいますが？方針が理解できていないのであれば(他利用者がそう思う場合を含む)そういった行動・権限行使は控えれば済みます。--Vigorous action （Ｔａｌｋ/History） 2016年5月28日 (土) 15:24 (UTC)

全般5について提案

削除版を確認できるのは管理者だけです。改善されているか管理者に判断を委ねるために全般5が貼られることも多いと思います。管理者がテンプレートを剥がすなら納得できますが、削除版を確認できない一般利用者が剥がしても説得力がありません。貼った者を荒らし扱いして剥がす者もいます。特に削除版を確認できるのが管理者だけというのを知らない初心者は貼ったり剥がしたりで編集合戦になってしまうことも多いと思います。そこで提案なのですが、全般5のテンプレート内に以下のような文言を表示させるのはどうでしょうか？

「管理者以外が剥がすと差し戻されます。」

というような感じの文言です。いかがでしょうか？もっと適切な文言があればそれでもかまいません。無いよりは有った方がいいと思います。--115.177.41.248 2016年6月3日 (金) 08:23 (UTC)

コメント 不要です。全般5の適用には前提となる通常の削除依頼がある訳ですが、ケースFや全般8の適用によって終了しケースEとして確たる合意が形成されないままのことがあります。そういった場合は改めて削除依頼での合意形成が必要で、全般5のテンプレートを見かけた一般利用者が剥がすことに何の問題もありません。また一般利用者でも、やろうと思えばデータベース・ダンプを見れば結構遡って確認できますよ。そこまでの手間をかけなくても、最近削除された記事だったなら内容を覚えていることもありますし。

それに、削除版を確認できないのは全般5を貼り付けた一般利用者も同じですよね。剥がすより貼る方が先なのですから、何故「管理者以外が貼ると剥がされます。」というご提案にしなかったのでしょうか（それもまあ無茶な話ですが）。--LudwigSK（Talk/History） 2016年6月3日 (金) 09:26 (UTC)

反対 そういった文言を追加すると、管理者以外が剥がしたときに編集合戦を誘発します。即時削除に反対があったときには削除依頼に出せばいいので、即時削除にこだわる必要はありません。むしろ、他の利用者が即時削除を剥がしてもなお削除を主張したいときは削除依頼に出すという運用の周知徹底を図るべきであります。--Ohgi 2016年6月3日 (金) 09:45 (UTC)

反対 即時削除で遊びたい方から見れば問題があるのかもしれませんが、普通の参加者には何の問題もありませんので大丈夫です。削除版の確認云々は解決済ですが何を寝ぼけているのでしょう。--Hisagi（会話） 2016年6月3日 (金) 10:37 (UTC)

ノートページの即時削除について

ノートページの初版がWikipedia:ノートページのガイドラインにそぐわない記載だった場合に内容によって全般1から3などに基づき即時削除依頼することがあります。しかし管理者/削除者によって対応が異なる場合があり削除なさる方もいらっしゃれば「積極的に削除する理由はない」と白紙化するだけの方もいますのでいっそのこと基準を設けて判断をできるだけ統一するべきではないかと考えるのです。もし基準を設けるとして以下の2つを案を考えているのですがどうでしょうか？

1. 原則的に著作権など各種権利の侵害など法的リスクがある場合のみ削除でリスクがない場合は白紙化で対応。
2. 法的リスクももちろんWikipedia:ノートページのガイドラインにそぐわない記載だった場合はできるだけ削除。

削除しないことにるメリットは削除作業も即時削除依頼も減ることで管理者/削除者の負担が減ることが期待できることで、デメリットはWikipedia:ノートページのガイドラインにそぐわない記載をしてもいいという誤解が生じて悪戯行為が頻発する可能性や白紙化しても青リンクのままなので何か書かれていると勘違いして無駄なアクセスが増えることが考えられます。--K-iczn（会話） 2016年6月9日 (木) 14:14 (UTC)

（1案に賛成）「積極的に削除する理由はない」と白紙化するだけの管理者です。標準名前空間以外にあるものについて、法的リスク等の積極的な削除されるべき事情がないときに、削除をする意味がよくわかりません。「管理者/削除者の負担が減る」は明らかなメリットでありますが、「悪戯行為が頻発する可能性」は可能性レベルであって実際に発生するかどうかOhgiは懐疑的です。「何か書かれていると勘違い」という発想をいままでしたことがなかったのですが、たとえば{{Blp}}が貼ってあるだけのノートを開いて損する気持ちと本質的には同じものであり、削除すべきかどうかで考慮される事情にはあたらないと判断します。「無駄なアクセス」につきましてはサーバの負荷を気にしすぎないでいいんだと思います。Wikipedia:ノートページのガイドラインにそぐうかそぐわないかという判断は、削除すべきかどうかの判断とは別にあるべきです。

また、上記#リダイレクト5の再改定提案でも議論がなされておりますが、リダイレクト5の必要性はどこにあるのでしょうか。削除の合意があるものという要件がついており、特段の削除されるべき事情がある場合には適用されてもよいと考えます。しかし、「いらないから削除」という消極的理由による合意ばかりが目立ち、どこに削除する意味があるのかよくわかっていないながらも（Ohgiの私見ばかりを強硬に主張するわけにもいかないので）即時削除対処している状況です。

なお、即時削除の方針に該当するものについて管理者・削除者によって削除するかしないかがわかれるのは、「管理者および削除者はページを見たその場で削除することができます」と即時削除をするかどうかの判断が管理者・削除者の主観に委ねられている以上当然のことであることを確認します。Ohgiは即時削除の方針に該当しないから削除しないのではなくて、即時削除の方針に該当するけど削除の必要がないから削除しないということです。しかし、意見の幅はあっていいと思う一方、無駄な削除がなされるのもよくないことでありますので、判断をできるだけ統一するという方向には賛成します。--Ohgi 2016年6月9日 (木) 14:45 (UTC)

コメント全般1から3のようなケースは、主ページだと白紙化してもページが存在していることで混乱を生むから、白紙化ではなく削除すべき。しかし、ノートではそんなこともないので、判断が分かれがちになるのだと思います。なお、白紙化しているのですから、「Wikipedia:ノートページのガイドラインにそぐわない記載をしてもいい」と受け取る余地はないでしょう。

基本的に、削除すること、削除しようとすること自体がコストとなりますから、削除しなくていいなら削除しないって方向で考えるのがよいと思ってます。方針にあるのは、「削除できる」ものの列挙で、該当するからといって削除しなければならないということではない。削除しなければならないものだけ削除する。とはいえ、「ノートページを除く」または「主ページ／表のページが存在しない場合に限る」などとしても、方針に該当しているなら削除しても問題はなく、かえって方針の内容が複雑になってしまう。正しく全般1から3に該当するなら、透明性が損なわれたり、削除によって何か悪さができたりというものではないはずですし、管理者／削除者としては、ページを開いてしまったら全削除と白紙化では労力もそんなに変わらないから、削除しちゃうってこともあるのでしょう。

個人的には、ここは判断揺れてもそれほど影響はなく、管理者／削除者のところというよりは、依頼者の段階でできるだけ依頼をしない、ということにしてもらえるのがよいと思ってます。

あるいは、「方針は、削除できる対象を列挙しています。削除しなければならないものを列挙しているのではありません。依頼者、対処者は、白紙化や移動などの手段で解消できないものについてのみ、依頼・対処を行うようにしてください」と、明文化する。--Ks aka 98（会話） 2016年6月9日 (木) 15:10 (UTC)

「削除しなくていいなら削除しない」の理由は、「管理者・削除者のコスト」のみではないと考えます。特殊な権限を預かっている以上、行使には原則として抑制的であるべきであって、権限は使わなくていいときには使わないべきだと考えています。--Ohgi 2016年6月10日 (金) 07:42 (UTC)

管理者権限は「削除しなければならないものは残らず削除」というより「削除できるものを吟味して削除」という態度で行使する、換言すれば必然性がなければ削除しないという大原則を恥ずかしながら管理者就任から数ヵ月かけてようやく私は理解しました。丹精込めて書いた記事の神聖なノートページを汚されるのはなんともいえない不快な感情になり過去の私だったら迷わず即時削除テンプレを張り付けてましたし、管理者就任後もしばらくは何らかの理由をつけて即時削除していた時期もあった気がします。私のような誤解を生まないように「不要な依頼は提出しないよう」と明文化する方向で良いと思います。ただ、過去の私のように「悪戯投稿のためだけに白紙のノートページが生成されるのがどうしても気にくわない」という利用者を救済するための措置を用意してもいいかもしれません。具体的には「これは○○のノートページです。記事作成に関する議論以外は除去されます。」といったダミーテンプレで置換しても良いと合わせて明文化するのです。これなら多少のサーバーへの負荷はあるでしょうが限られた管理者の人的資源を浪費することもなくなるでしょう。--Damena（会話） 2016年6月9日 (木) 21:19 (UTC)

「悪戯行為が頻発する可能性」は可能性レベルではないか、とのことですが、ノートページで悪戯やエッセイや政治的主張などをあちこちで書きまくる輩の場合、「たとえ除去されても自らの主張が履歴として残る」ことに快感を覚えると思いますよ。白紙化するだけではこういった輩の思うツボかもしれません。また、ノートページに悪戯書きがなされた場合、見つけた利用者が即時削除を貼らずに自ら白紙化することはいいですが、もし即時削除タグを貼ったのであれば、削除するのと、わざわざ理由を説明してタグを除去して白紙化するのとでは、どちらもかかる手間に大きな差はないでしょう。--Muyo（会話） 2016年6月10日 (金) 01:39 (UTC)

おそらくLTA:AA等を想定していらっしゃるかと思いますが、「履歴として残ることが快感」の長期荒らしもあれば、「削除されることが快感」の長期荒らしもあるんだと思います。履歴として残ることが快感のタイプは、白紙化で解消できない削除されるべきものであると理解しますので、その点を考慮した削除は否定しません。--Ohgi 2016年6月10日 (金) 07:42 (UTC)

コメント 自分としては、2の「ノートページであっても積極的に削除すべき」と考えます。上でMuyoさんが書いているように、{{sd}}の貼られた状況下では、管理者の手間はむしろ削除してしまうほうが少ない可能性もあります。そして、仮に1のような運用が普及してきたとすると、一般ユーザーについても「不適切なノートはSDを貼らずに白紙化する」というような流れとなることでしょう。その過程の中で、著作権侵害や名誉毀損に当たるようなWP:DEL#Bとなっているノートすら白紙化だけがされて、法的リスクを含んだまま放置される、というリスクが残ることが考えられます。ということで、権利上問題はないけどWP:CSDに該当する無意味なノートについても、削除を徹底した方がいいと考えます。--Jkr2255 2016年6月10日 (金) 03:37 (UTC)

確かにそういった流れになることもありえるかもしれませんが、問題のないノートは白紙化という流れだけになるわけではありません。どちらかといえば「著作権など各種権利の侵害など法的リスクがある場合」と「それ以外」を区別する流れになってくると思われ、一旦法的リスクが存在するかどうか検討されている以上、多少そうしたリスクが残ったとしても大きな問題にはならないと考えます。--Ohgi 2016年6月10日 (金) 07:42 (UTC)

リダイレクト3はノートページに適用できるのか

確認なんですが、現時点でWikipedia:即時削除の方針#リダイレクト3はそれに付随するノートページに適用できるものでしょうか。適用できるとすると、Wikipedia:即時削除の方針#リダイレクト5が「括弧つき曖昧さ回避」があるかどうかで適用基準が全く異なることになります。具体的にはPOP (アイドルグループ)が改名提案によって移動された後、ノート:POP (アイドルグループ)が表と一緒にWP:CSD#リダイレクト3-1で削除されており、これは運用上問題がないのかを確認したいです。なお、改名提案においては、ノートページの削除については合意が無いためWP:CSD#リダイレクト5の適用はできません。--アルトクール（会話） 2016年7月5日 (火) 07:58 (UTC)

• コメント　Wikipedia:即時削除の方針#リダイレクト5の兼ね合いなどを考慮するとWP:CSD#リダイレクト3-1には「事前に改名の議論を経て合意を得た移動により発生したもの」と有ります。なのでノートページについても改名議論によって移動するとの合意があれば即時削除しても構わない程度の合意があるとみなせると思います。例えば、改名議論でノートページについても同時移動の提案があり、移動で合意形成がされていればWP:CSD#リダイレクト3-1の適用でも問題がないといえるでしょうが、それがない場合合意や強いて削除しなければならない理由は有りませんから、WP:RFDの対象と考えるべきなのだと思います。--Vigorous action （Ｔａｌｋ/History） 2016年7月6日 (水) 14:34 (UTC)

リダイレクト5は、2010年春にWikipedia‐ノート:即時削除の方針/過去ログ12#「合意を得た移動により発生したノートへのリダイレクト」を追加する案にて追加されていますが、残念なことに提案理由がなく、どなたの反応もありませんでした。

察するに、リダイレクト5がない時代には括弧付きは、記事・ノート共々 3-1の適用であり、括弧のないリダイレクトのノートを削除する理由が生じたのだと思います。

私は、可能な限り 3-1適用、そこからはみ出した部分に 5を使うのが適切だろうと思っています。

私の考えとしては、記事側にリダイレクトとして残っていれば、ノート側は消すまでもないだろうなのですが、この件については当時の提案者に呼びかけてみました。--Triglav（会話） 2016年7月7日 (木) 00:34 (UTC)

Triglavさんに呼ばれてきました、2010年にリダイレクト5を提案した者です。昔のことなうえ自分の即時削除依頼は投稿記録から確認できないので当時の経緯は定かではありませんが、背景としてはそれまで単に「移動の残骸」を理由としたリダイレクトの削除依頼 (および執行) が頻発しており、その簡略・円滑化を実現する意図だったと記憶しています。その後の種々のノートページでの議論は膨大なので詳しく把握していませんが、履歴保全等の観点から、「移動の残骸」のみを理由としたリダイレクトの削除依頼や、そもそも改名に伴って生まれた移動元のリダイレクトをむやみに削除することに疑問を呈する声が上がり、WP:CSDやWP:CRDが見直されてきたものだろうと個人的には理解しています (個人的にも今ではこうした視点には賛同しており、今だったら当時と同様の提案はしないと思います)。しかしそうした議論の結果このリダイレクト5自体かなり狭義なものとなっていて、実際どれくらいの頻度で適用されているのか存じませんが、もはや狭義すぎて、廃止してWP:RFDに任してしまった方が (記録の観点からも) よいのではないかとすら思えます。

表題の件ですが、私はずばり「できない」がその答えだと思います。そもそも「(記事名に括弧を付けることによる) 曖昧さ回避」とは標準名前空間 (やその他非ノート名前空間) において行われるものであり、ノートページに「曖昧さ回避」という概念は存在しません。ノートページはすべての非ノート名前空間のページに「付随して」存在するものであり、「先立って」存在することは決してありえません (時系列においてはありえますが、従属関係として)。もしノートページにおいて括弧による曖昧さ回避と同じような概念があるとしたら、それはスラッシュによるサブページ化です。したがって、「リダイレクト3」のいう「項目名に曖昧さ回避の括弧を含むリダイレクト」をノートページを含むものと考えること自体に無理があると思います。なお本節と同様の議論は/過去ログ15#ノートページとリダイレクト3-1でも行われていたようで、皆様がどちらと考え合意されるかにかかわらずいずれにせよ適用範囲の明確化はしておいた方がよさそうです。--Purposefree（会話） 2016年7月7日 (木) 06:03 (UTC)

解説ありがとうございます。

リダイレクト5追記以前からリダイレクト状態であればどの名前空間でも適用だったはずです。なぜなら記事は即時削除だがノートはリダイレクト削除行きということはなかったのですから、ノートがあればセットで 3-1として処理されていました。

2008-2009年ころリダイレクト削除依頼によく出入りしていたのですが、当時は「移動跡地を曖昧さ回避ページや別記事にするためにノートリダイレクトを削除する」というパターンが目立っていたような記憶があります。私も（ノートを削除したほうがノートをクリックしたときに削除ログを見せることが出来るので）積極的に削除票を入れていました。（これがたしか当時流行の「移動の残骸」として依頼が乱発していて、そんな削除理由はないと反発した覚えが（笑））。

ですが、2012年よりTemplate:移動済みノートが作られ、削除ログを見せることへの代用となったため、もしリダイレクト5設置の目的がこのパターンのみであれば、リダイレクト5は廃止として、残りのレアケースはリダイレクト削除行きということでよい気がしています。--Triglav（会話） 2016年7月7日 (木) 11:58 (UTC)

過去ログを見てみたんですが、Wikipedia‐ノート:即時削除の方針/過去ログ12#「合意を得た移動により発生したノートへのリダイレクト」を追加する案でリダイレクト5が初めて設定されたわけですが、それに至る議論がよくわからない状態（追加直近1年以内にWikipedia‐ノート:即時削除の方針/過去ログ12#ノートの移動残骸、Wikipedia‐ノート:即時削除の方針/過去ログ12#リダイレクトに2点追加提案がありますが、両方とも追加合意に達したとは言えない状態）です。「リダイレクト5」自体の設定目的をはっきり把握できている人はいないのではないかとも思います。現状の設定文言を見る限りは「ノートのリダイレクトはどのような場合であれ削除の合意が必要」といえるんじゃないかという思いに変わりはありません。過去には「ノートページはノートページで特別に合意が必要（Wikipedia‐ノート:即時削除の方針/過去ログ16#事前の改名議論なしに移動されたカテゴリ）という意見もあります。リダイレクト5設定以前は一緒に対応していたという話ですが、それは設定前の慣例とかそういう話ですからそれを根拠に「リダイレクト3でノートも一緒に削除できる」というのは少し乱暴ではないでしょうか。

あと、リダイレクト3はWikipedia‐ノート:即時削除の方針/過去ログ9#対象の明文化と追加の提案(20071213)を受けて追加されたわけなんですが、そもそも設定根拠になる方針文書ってあるのでしょうか？私の見落としかもしれないんですが、もし知っている方がいれば教えていただけませんか？--アルトクール（会話） 2016年8月1日 (月) 14:24 (UTC)

もちろん処置者の独断ではなく、ノート側にもsdタグを貼ってもらっての処理です。案内テンプレート等によって削除意義が薄れた現在においては、少なくとも「リダイレクト5」の役割は終わっていると考えてよいでしょう。その上で、時代を遡る形で「リダイレクト3」の有用性についての審議も別に構えるとよいと思います。特に問題が無ければ「リダイレクト5」の廃止提案を提出します。--Triglav（会話） 2016年9月25日 (日) 11:40 (UTC)

2012 年秋冬の議論 Wikipedia‐ノート:即時削除の方針/過去ログ15#リダイレクト3-1はノートも対象か （上位節はWikipedia‐ノート:即時削除の方針/過去ログ15#ノートページとリダイレクト3-1） で、3 からノートを外す方向で進めていたのですが、結論を得ないままうやむやにしてしまいました。ごめんなさい。移動済みノートができたときの議論は、Wikipedia‐ノート:ページの改名#移動に伴って作成されたノートページのリダイレクトについて で、「ノートは原則として残す（移動済みノート優先）」という考えに基づいていました。Wikipedia:ページの改名#ノートページのリダイレクト も、リダイレクト 5 による処理は、その後の機能追加で管理者・削除者なら「リダイレクトを作らずに移動」するような案件を意識していたはずです。ところが、リダイレクトがあることを望む方はわざわざ移動済みノートに置き換える必要を感じないのでしょうか（リダイレクト削除除けのお札とは明記していませんから）、貼らない方も多いようです。#CSDリダイレクト5廃止提案 で議論がありますので、こちらでは過去ログの紹介まで。--Kurihaya（会話） 2017年5月18日 (木) 10:30 (UTC)