「Wikipedia‐ノート:即時削除の方針」の版間の差分

文面を素直に読めば、たとえばファイルページに「この画像の転載を禁止します」等の記載がある場合を想定しているものと考えられます。しかし、そういった場合は（適当なライセンスタグが貼り付けられているのに転載を禁止する記載があるような矛盾した場合を除いて）ファイル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)[返信]
例

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

利用者:にょろん/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つを案を考えているのですがどうでしょうか？

原則的に著作権など各種権利の侵害など法的リスクがある場合のみ削除でリスクがない場合は白紙化で対応。
法的リスクももちろん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に該当する無意味なノートについても、削除を徹底した方がいいと考えます。--Jkr 22 55 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)[返信]

@@ 177行目: / 177行目: @@
 :: Triglavさんに呼ばれてきました、2010年にリダイレクト5を提案した者です。昔のことなうえ自分の即時削除依頼は投稿記録から確認できないので当時の経緯は定かではありませんが、背景としてはそれまで単に「移動の残骸」を理由としたリダイレクトの削除依頼 (および執行) が頻発しており、その簡略・円滑化を実現する意図だったと記憶しています。その後の種々のノートページでの議論は膨大なので詳しく把握していませんが、履歴保全等の観点から、「移動の残骸」のみを理由としたリダイレクトの削除依頼や、そもそも改名に伴って生まれた移動元のリダイレクトをむやみに削除することに疑問を呈する声が上がり、[[WP:CSD]]や[[WP:CRD]]が見直されてきたものだろうと個人的には理解しています (個人的にも今ではこうした視点には賛同しており、今だったら当時と同様の提案はしないと思います)。しかしそうした議論の結果このリダイレクト5自体かなり狭義なものとなっていて、実際どれくらいの頻度で適用されているのか存じませんが、もはや狭義すぎて、廃止して[[WP:RFD]]に任してしまった方が (記録の観点からも) よいのではないかとすら思えます。
 :: 表題の件ですが、私はずばり「できない」がその答えだと思います。そもそも「(記事名に括弧を付けることによる) 曖昧さ回避」とは標準名前空間 (やその他非ノート名前空間) において行われるものであり、ノートページに「曖昧さ回避」という概念は存在しません。ノートページはすべての非ノート名前空間のページに「付随して」存在するものであり、「先立って」存在することは決してありえません (時系列においてはありえますが、従属関係として)。もしノートページにおいて括弧による曖昧さ回避と同じような概念があるとしたら、それはスラッシュによる[[Help:サブページ|サブページ化]]です。したがって、「リダイレクト3」のいう「項目名に曖昧さ回避の括弧を含むリダイレクト」をノートページを含むものと考えること自体に無理があると思います。なお本節と同様の議論は[[/過去ログ15#ノートページとリダイレクト3-1]]でも行われていたようで、皆様がどちらと考え合意されるかにかかわらずいずれにせよ適用範囲の明確化はしておいた方がよさそうです。--[[利用者:Purposefree|Purposefree]]（[[利用者‐会話:Purposefree|会話]]） 2016年7月7日 (木) 06:03 (UTC)
+:::解説ありがとうございます。
+:::リダイレクト5追記以前からリダイレクト状態であればどの名前空間でも適用だったはずです。なぜなら記事は即時削除だがノートはリダイレクト削除行きということはなかったのですから、[https://ja-two.iwiki.icu/w/index.php?title=%E7%89%B9%E5%88%A5:%E3%83%AD%E3%82%B0&offset=20100301000000&limit=500&type=delete&user=&page=&tagfilter=&subtype=&month=2&year=2010 ノートがあればセットで 3-1として処理]されていました。
+:::2008-2009年ころリダイレクト削除依頼によく出入りしていたのですが、当時は「移動跡地を曖昧さ回避ページや別記事にするためにノートリダイレクトを削除する」というパターンが目立っていたような記憶があります。私も（ノートを削除したほうがノートをクリックしたときに削除ログを見せることが出来るので）積極的に削除票を入れていました。（これがたしか当時流行の「移動の残骸」として依頼が乱発していて、そんな削除理由はないと反発した覚えが（笑））。
+:::ですが、2012年より[[Template:移動済みノート]]が作られ、削除ログを見せることへの代用となったため、もしリダイレクト5設置の目的がこのパターンのみであれば、リダイレクト5は廃止として、残りのレアケースはリダイレクト削除行きということでよい気がしています。--[[利用者:Triglav|Triglav]]（[[利用者‐会話:Triglav|会話]]） 2016年7月7日 (木) 11:58 (UTC)