コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia‐ノート:リダイレクトの削除依頼

ページのコンテンツが他言語でサポートされていません。

これはこのページの過去の版です。Y-route (会話 | 投稿記録) による 2023年1月22日 (日) 15:21個人設定で未設定ならUTC)時点の版 (新規利用者の投票資格を制限する提案: 取り下げ。)であり、現在の版とは大きく異なる場合があります。

このページには削除された版があります。削除に関する議論はWikipedia:削除依頼/Wikipedia:リダイレクトの削除依頼をご覧ください。


議論を始める前に、類似の議論がないかを確認するため、次のページも参照してください。

過去ログ

  • ログ1 - 2008年2月7日までの議論のログ。削除のルール再確認を、書式の変更、ログ化補足、 Wikipedia:リダイレクト削除の方針、削除するべきではないリダイレクト、移動に伴って削除された記事のノートの処理について、対処保留の依頼のこと、「ページの移動」をクリックしたときに現れる注記、リダイレクトの削除依頼改善のための提案、複数のリダイレクトを同時に削除依頼する場合の書式、依頼終了の際の依頼文削除のタイミング、お知らせ: 括弧付きの移動の残滓を即時削除対象にする提案、テンプレート変更案。
  • ログ2 - 2008年2月 - 2016年3月
  • 依頼告知関連過去ログ - RFDの依頼告知関連議論

文章変更の提案

現在、この文書には「それぞれのページで審議が終了したものは、しばらくするとページから削除されます。」という文章がありますが、この文章を削除することを提案します。提案理由は、後日調査をする際の作業を軽減することです。現在のルール(「審議が終了したものは削除する」)だと、削除されたことのあるリダイレクトを作成しようとして、以前に削除の議論が行われたことがわかっても、「Wikipedia:リダイレクトの削除依頼/×年×月」ですぐに以前の議論を確認することができません。もちろん過去ログを最古のものまで順次調べれば見つけることができます。しかし、審議が終わっても削除しないことにしておけば、最新版を見れば全部の削除依頼に対する議論を見ることができ過去ログを調べる必要はありません。また、リダイレクトの削除記録の中には「Wikipedia:リダイレクトの削除依頼/×年×月」へリンクしていないものもありますが、審議の記録を削除しなければ「リンク元」でどのページで議論したかを見つけるのは容易です。以前は「Wikipedia:リダイレクトの削除依頼/×年×月」に分かれておらず、「Wikipedia:リダイレクトの削除依頼」に直接依頼が行われていて、どんどん肥大化する恐れがあり「審議が終了したものは削除する」というルールになったのでしょうが、現在の「Wikipedia:リダイレクトの削除依頼/×年×月」では「×年×月」以降にあらたな削除依頼が追加されることはないのでそれぞれの文書がどんどん肥大化するということはありません。以上の理由により、上記の文章を削除し、現在継続中の議論も含めて今後は審議の記録を削除しないことを提案します。ツバル会話2017年1月12日 (木) 23:43 (UTC)[返信]

過去ログ処理をどうするか? ですね。現在の「過去版参照」方式は事例検索として不向きですので、検索を可能とする方式への切り替えは賛成です。処置最終日に近づくと残件が完了案件に埋もれてしまいますので、各月の審議ページの一番上に == 過去ログ == を設置して、そこに終了分を移設。折り畳み機能を使用すれば表示上は苦にならないと思います。作業自体は1月分より可能かと思いますが、Dr jimmy様いかがでしょうか? 昨年以前はBotによるサルベージを考えてみます。--Triglav会話2017年1月13日 (金) 02:57 (UTC)[返信]
ちょうど区切りもいいですし、よろしいかと思います。1月分の終了分は削除せず、しばらく様子を見ることにいたします。--Dr.Jimmy会話2017年1月13日 (金) 03:23 (UTC)[返信]
ありがとうございます。月末時点の使い勝手を確認してみましょう。--Triglav会話2017年1月13日 (金) 06:43 (UTC)[返信]
コメント 2017年1月が全件終了になりました。ただ、冒頭を{{リダイレクトの削除依頼 (終了)}}に単純に置き換えていいものか迷ったので置き換えはしていません。
ここ1カ月ほど削除対処している側からすると、notice=noを入れないといけないのが手間と言えば手間(管理者が忘れても別の方が追加してくれているので今はどうにかなってますけど)なのと、懸念事項であった「未対処の案件が対処案件に埋もれてしまいがちになる」はやっぱりありました。あと、終了案件を折りたたみしてしまうという話ですが、それをやると結局検索で飛んできたときに「折り畳みを解除する手間」を発生させることになりますので微妙です。それなら、対処済み案件を旬ごとの一番上に移すなりしたほうがまだ手間がかかりません。ここで話している人はまだいいですけど、リダイレクトの削除依頼の対応に今以上に手間がかかるようになれば、管理者・削除者の中で対応を敬遠してしまう人が出ないとも限りません(ただでさえ、復帰依頼や利用者ページの削除依頼と同じで対処する人が固定メンバーなんですし)。人力対応する部分でも少しでも手間を省かないと、未処理案件が増えるだけです。--アルトクール会話2017年2月27日 (月) 16:55 (UTC)[返信]
コメント 1か月分まるまる残るとなると見た目が重苦しいですね。それに、スクロールは我慢できたとしても、noticeのフラグを付ける作業は確かに余計です。では、「Wikipedia:リダイレクトの削除依頼/×年×月/ログ」を作成し、井戸端Botを流用して転記してみましょうか? divの閉じ忘れの心配もありますが、失敗したら転記元・先の両方を差し戻して、翌日のBotに再度やらせましょう。規約の「1週間程度掲載の後に除去してください」をなくす必要がありますが、転記ですから問題はないでしょう。--Triglav会話2017年2月27日 (月) 19:56 (UTC)[返信]
コメント divの閉じ忘れは今更なので・・・。RFDの形式そのものを変更するということも考えたほうが良いんじゃないかとは思います。目指すところはmeta:Steward requests/Global permissions/2017-02のようなアーカイブ化(metaで走っているSteinsplitterBotがたぶんその理想ですよね?)でしょうから、それならばいっそのこと月別依頼ページではなくて、依頼自身はWikipedia:リダイレクトの削除依頼あるいは別に設ける専用依頼ページで受けるようにだけして、アーカイブを月別に設けてしまったほうが良いのではないかとも感じます。そうすれば定期的な貝塚送りは発生しますが、階層的にはすっきりすると思うのですが。--アルトクール会話2017年2月28日 (火) 08:04 (UTC)[返信]
Wikipedia:管理者伝言板/投稿ブロックのように受付を単ページ化して、そこに月ごとのアーカイブ処理を付け加える感じでしょうか? 対象が1ページのみとなればログ化もやりやすいです。--Triglav会話2017年2月28日 (火) 11:26 (UTC)[返信]
  • 依頼ページ(2017年4月新規または2月3月受付中のものを転記)
    • 「Wikipedia:リダイレクトの削除依頼/???」
  • 昨年までのログページ(依頼ページをそのまま転用、サルベージ作業は後日)
    • 「Wikipedia:リダイレクトの削除依頼/×年×月」
  • 本年2017年の1-3月分(ページ名はそのまま)
    • 「Wikipedia:リダイレクトの削除依頼/2017年×月」
--Triglav会話2017年2月28日 (火) 11:38 (UTC)[返信]

(インデント戻す) そうです。単ページ化すれば、例えば会話ページで依頼へ誘導するときも楽でしょうし、Botで変数を拾わせる手間も減ります。何より仮にBotが停止したときでも人力で対処できる範囲になります。また、現状のRFDの誘導を張り付けるBotの判定基準を「依頼受付ページ」に限定すればよくなります。対処した後に議論をするわけでもないので、一定期間対処ログを受付ページに残しておく必要性がない(ログ送りにするわけですから、依頼そのものが除去されるわけではない)といえるから、2月に行ったnotice=noの付与を対処時に付け加える手間も減ります。履歴継承については、ログ送りというだけで誰が投稿したのかの履歴は「本文自体に付与」されていますので目くじら立てて要約欄に記載を必須とする必要もありませんから、そのあたりで削除依頼が出される可能性も低いです。サルベージはお任せするとして、3月はスタートしたので、2月と同様に対応するとして、4月から対応できないかで検討に入ったほうが良いでしょう。依頼受付ページはWikipedia:リダイレクトの削除依頼/受付あたりでやるとして、Wikipedia:リダイレクトの削除依頼は依頼の方法や依頼者資格、管理者・削除者向けの対応マニュアルなどを整備する方向で考えてはどうでしょうか。--アルトクール会話2017年3月1日 (水) 02:38 (UTC)[返信]

Wikipedia:リダイレクトの削除依頼/受付 - 投稿ブロックと書式を合わせてみました。節は月末に3節6節を自動作成します。--Triglav会話2017年3月12日 (日) 14:44 (UTC) 節数変更[返信]

ショートカット作成提案

Wikipedia:リダイレクトの削除依頼/受付 への切り替えはうまくいっていますね。過去ログも見やすくて助かります。ありがとうございます。さて、WP:VFD/TW のように依頼受付ページへのショートカットがあると便利かと思うのですが、いかがでしょうか。WP:RFD のリダイレクト先を変えてしまうのは乱暴な気もしますが、/C (current), /TM (this month), /U (受付)とか、何か良いものがあるでしょうか。--Kurihaya会話2017年5月10日 (水) 10:21 (UTC)[返信]

賛成 受付ページへのショートカットの作成に賛成いたします。ショートカット名の案として/P (pending)が思いつきました。--本日晴天会話2017年6月8日 (木) 13:34 (UTC)[返信]
賛成 ショートカットなのですから括弧付きより括弧無しの方が検索しやすいでしょう。そうですね、/RECや/Rなどはどうでしょうか。英語で受付を意味するReceptionの頭文字を取ってみました。最初はGoogleで検索して出てきたacceptanceから取った/ACが思いついたのですがよく調べたら意味が少し違っていたのでRECにしました。--赤羽さん会話2017年7月29日 (土) 00:58 (UTC)[返信]
賛成 ショートカットの作成自体は賛成です。「受付」という言葉にとらわれない(本来的な「依頼場所」という部分)で、 /R(受付/receptionの頭文字、赤羽さんの案)、/OD(依頼発注とみてorderから)、/RD(依頼場所ということでrequest deskから)は候補に挙げられるかと思います。せっかくのショートカットなので、「WP:RFD/xx」でxxが長いと本末転倒なのでできれば増やす部分は2文字以内が妥当なところかと思います。--アルトクール会話2017年8月1日 (火) 15:49 (UTC)[返信]
コメント ここの議論が停滞しちゃってるので、上から進めようと思います。さて、私はショートカットの作成に賛成します(一応意見表明)。
現状はWP:RFDの後ろに「/P」(本日晴天さん案)「/REC」「/R」(赤羽さん案)「/OD」「/RD」(アルトクールさん案)をつける5つの案が挙がっていますが、この中から投票で決めるということでいいでしょうか。--Yuukin0248[会話/履歴] 2017年8月28日 (月) 08:39 (UTC)[返信]

半年ほど経過しました。リダイレクト設置に賛成のご意見が寄せられているので、どれかを選んで決めてしまいましょう。議論参加者は限られており、リダイレクトの削除依頼にいらっしゃる方も多くはありませんし、急ぐものでもありませんので日程は長めに取ります。思いつく論点を箇条書きにしたので、ご意見をお願いします。もちろん論点追加もご自由にどうぞ。--Kurihaya会話2017年11月6日 (月) 09:12 (UTC)[返信]

  • (日程)本日から 16 日までを投票のための準備期間として、投票資格、投票方法、リダイレクト候補その他必要事項の議論を行い、17 日 0 時 (UTC) から 30 日 24 時 (UTC) までを投票期間としてはいかがでしょうか。もっと長くても構いません。複数候補が最多得票を得た場合は、決選投票期間を設けます。--Kurihaya会話2017年11月6日 (月) 09:12 (UTC)[返信]
    • コメント 私が完全に失念していたところ、進めてくださりありがとうこざいます。8月28日のコメントではKurihayaさんの提案文にある案を見逃しており、申し訳ありません。本題ですが、暫定的なものなので修正を急ぐものではありませんが、「投票」節の投票期間が 16日0時 からとなってしまっています。Kurihayaさんの提案では 17日0時 からのはずです。--Yuukin0248[会話/履歴] 2017年11月7日 (火) 10:10 (UTC)[返信]
  • (投票資格)リダイレクトの削除依頼に合わせて、登録利用者(副アカウントを除く)としましょうか。削除ほどの影響はありませんから、多重投票の疑いを招かないようお願いしつつ IP 利用者にも資格を認める考えもあるでしょう。--Kurihaya会話2017年11月6日 (月) 09:12 (UTC)[返信]
  • (投票可能数・累積投票)これまでのところ強くこれというご意見でもなさそうです。1 利用者当たり 3 票まで投票可能とし、累積投票可能(同一候補に 3 票投じることも、三つの候補に各 1 票投じることもできる)とすると、それなりに票が重なって決まってくれそうです。--Kurihaya会話2017年11月6日 (月) 09:12 (UTC)[返信]
  • (リダイレクト候補)これまで出た案を中心に並べてみました(this month は実態に合わないので止めにして、AFD, VFD から /a, /v を加えてみました)。準備期間中は候補の追加を受け付けます。投票節にアルファベット順で追加してください。--Kurihaya会話2017年11月6日 (月) 09:12 (UTC)[返信]

特段のご意見がなければ、このまま投票に移ります。--Kurihaya会話2017年11月16日 (木) 09:54 (UTC)[返信]

投票

投票期間: 2017 年 11 月 17 日 0 時 (UTC) から 2017 年 11 月 30 日 24 時 (UTC) まで。

投票資格: 特段の制限なし(IP 利用者の方は同一判定が難しいため、複数票でも一度に投票するなど、ご協力ください。複数アカウントの利用は禁じます。)

投票可能数: 1 利用者当たり 3 票まで。

累積投票: 可

リダイレクト候補(括弧内は由来です。リダイレクトには / の後の数文字までを用います。)


投票の結果から、WP:RFD/R を採用します。ご協力ありがとうございました。--Kurihaya会話2017年12月1日 (金) 03:34 (UTC)[返信]

RFD.js 更新連絡

各員お手数ですがスクリプトの更新願います。利用者:Triglav/Triwiki/RFD.js

改名提案経由の移動先削除を「移動依頼」へ一本化する提案

先日扱ったWikipedia:リダイレクトの削除依頼/2017年4月#RFD伊藤亜由美ですが、Wikipedia:リダイレクト削除の方針#削除依頼における議論(予めノートページなどで削除の合意ができている場合)に従って削除を行いました。依頼では移動依頼案件として依頼提出先違いで存続票がありましたが、リダイレクトの削除依頼ではこうした依頼を排除するような規定はなかったために対処しました。

ただ、依頼提出先が2か所ある状態は好ましくないため、「改名提案を伴う移動先のリダイレクトの削除」について移動依頼へ誘導し、リダイレクトの削除依頼では扱わないように合意を得たく思います。合意が得られたら、Wikipedia:リダイレクトの削除依頼Template:リダイレクトの削除依頼で誘導を行います。--アルトクール会話2017年4月24日 (月) 15:25 (UTC)[返信]

  • 賛成 過日の依頼で「依頼場所誤り」として即時存続票を投じた者です。改名先となるリダイレクト削除はリダイレクトの削除依頼でも扱える状態は混乱の元となりかねませんので、移動依頼へ一本化すべきだと思います。それでもなおリダイレクトの削除依頼に提出される案件が出た場合には、今度こそ「依頼場所誤り」による即時存続終了としていただくことに問題がなくなりますから、それで良いと思います。また、余談ですが、移動依頼では改名提案で合意が得られた案件以外に、即時改名可能なケース(記事名に書き誤り等明らかに問題があるとか改名提案にて合意を経ていない無断改名の差し戻し改名も含む。)も扱うため、それについても同様の取り扱いで良いと考えます。--Don-hide会話2017年4月25日 (火) 03:21 (UTC)[返信]
    • コメント 本提案ですが、趣旨からして「移動依頼で対処できる(もしくはすべき)案件については、今後リダイレクトの削除依頼では取り扱わない(依頼場所誤りとみなす)」と改訂すれば良いと思います。万一、今後本件改訂までの間、提出場所の一意性がないことでリダイレクトの削除依頼に出されたものがあった場合については「依頼場所誤り」での却下や即時存続票を投じることは不適当だといえないでしょうか(改訂前に依頼を提出した者の責めに帰す理由ではないためです)。--Don-hide会話2017年4月25日 (火) 08:24 (UTC)[返信]
  • 情報 コメント 現状のWikipedia:ページの改名#改名の仕方Wikipedia:改名提案#改名の手順のガイドラインは「移動依頼へ提出」とのみ指示があり、「リダイレクトの削除依頼に持ち込んでも良い」との明記がありません。そのため、指示文書間の齟齬が生じていたものと思われますし、これらをもとに「依頼場所誤り」ではないかと指摘することとなりました。提出場所に関して所望の改訂がなされれば、このような齟齬は解消され、依頼場所の一意化によって解消する問題と言えます。--Don-hide会話2017年4月25日 (火) 08:19 (UTC)[返信]
  • (コメント)移動の妨げとなるリダイレクトは、移動依頼で扱うのを原則とするということには賛成します。依頼者が迷わないように案内するのは良いことです。しかし、リダイレクトの削除依頼に付されたのであれば、今回の「伊藤亜由美」の件でアルトクールさんがていねいに説明してくださったように(まあここまでの水準は求めないにせよ)、移動依頼を案内しつつこちらで対処すれば足りるのではないでしょうか。話を拡散させてしまえば、利用者ページのリダイレクトも同様です。依頼場所相違だとして別の場所に移させても、再依頼の手間ばかりかかって、対処の手間も行使する権限も変わるわけではありません。こちらの審議も、「依頼場所相違、存続」と「次からは別の方に、削除」と、どちらでも対応できるはずです。受理しないとどのような良いことが起きますか。それよりも、不慣れな利用者に親切に対応して差し上げてはいかがでしょうか。--Kurihaya会話2017年4月25日 (火) 11:22 (UTC)[返信]
    • コメント 今回の話とはちょっと違うかも知れませんが、「リダイレクトの削除依頼」関連で提出箇所が複数あったものを一本化した例があります(当方が関わっていますので、記憶があります)。『「リダイレクトの削除依頼で扱える案件」かつ「利用者ページの削除依頼で扱える案件」』の場合、以前は「リダイレクトの削除依頼」でも「利用者ページの削除依頼」でも扱うことが可能となっていましたが、各削除依頼の削除審議の方向性や趣旨が異なることを鑑み、現在では「利用者ページの削除依頼」でしか受理されないこととなっています。無論、依頼場所誤りを指摘して即時存続票を投じるだけではなく、代理で本来の提出場所に提出することがあっても良いと思います(それに反対するつもりはないですし、今後そのような事案に出くわした場合、可能であれば当方はそうしたいと考えます)。ただ、一本化しても現状と何ら変わらないでは、規定を変える意味がございません(死文化される規定などわざわざ作る意味がない)ので、基本的には議論先の一意性を明文化し、依頼場所誤りが発生した場合、きちんとそれを指摘する必要はあるでしょう。何度も何度も同種の依頼場所誤りが繰り返される利用者がいた場合の対処に難があります。--Don-hide会話) 2017年4月25日 (火) 11:34 (UTC) 訂正。--Don-hide会話2017年4月25日 (火) 11:41 (UTC)[返信]
      • コメント 移動依頼を「推奨」(依頼場所違いとして却下されることがある)としておけばよいでしょうか。一律で却下すると手続きを行う上で煩雑さが増すだけです。移動依頼で対応できるものについては「管理者以外で気づいた方が移動依頼へ提出して、RFDは依頼無効とする」(リダイレクト先変更で問題ないとする例や、辞書的な転送をwiktへのソフトリダイレクトにしてしまう例などと同等の案件扱い)か、「管理者がそのまま対処してしまう」のどちらかで行けると思います。管理者がわざわざ「却下」するぐらいなら、その場で削除してしまうか移動してしまったほうが管理者としては対応が楽です。--アルトクール会話2017年5月3日 (水) 14:58 (UTC)[返信]
        • コメント 『「リダイレクトの削除依頼で扱える案件」かつ「利用者ページの削除依頼で扱える案件」』の場合との対応の食い違いが生じても問題だと思いますので、それとの整合性を取る必要があるように思います。つまり適切な提出先の「推奨」にとどめた場合、そのような案件がリダイレクトの削除依頼に出されたなら、現行では「依頼場所誤りによる即時存続終了」となっているところを、「管理者・削除者以外で気づいた方が利用者ページの削除依頼に代理提出し、リダイレクトの削除依頼は依頼無効とする」としなければならなくなると思いますが、いかがでしょうか。無論適切な提出先を一意に絞り、気づいた方が適切な依頼先に出し直すようにすれば、それはそれでよいのではないでしょうか。それと、個人的には方針文書の改訂が有効に働くためには、実効性を持たせなければと思います。実際の運用ではどっちでも良いになってしまってますと、文書類の改訂を行う意味が本当にあるのか、疑わしくなる懸念があります。--Don-hide会話2017年5月4日 (木) 08:17 (UTC)[返信]
          • コメント ちょっと待ってください。現行ではどこにも触れられていない(少なくとも改名提案やページの改名では移動依頼への誘導は行っているものの、「RFDでは扱ってはいけないもの」とはなっていない)ので、「依頼場所誤りによる即時終了」というのは、移動依頼で扱える案件のうち複数版リダイレクトもしくはリダイレクト先違いの例であれば、リダイレクトの削除依頼「でも扱える」ので即時終了にはなりません。完全に禁止したいのであれば、それはリダイレクト削除の方針ではっきりと依頼場所を指定する改定が必要になります。--アルトクール会話2017年5月7日 (日) 12:41 (UTC)[返信]
        • (コメント)「推奨」が妥当だと考えます。移動依頼の方が対処が早かったりもしますし。例えば著作物性の有無の判断を通常の削除依頼に回送するため存続終了とするのはていねいな議論が求められるためであり、本件とは異なります。--Kurihaya会話2017年5月9日 (火) 09:22 (UTC)[返信]
コメント 一本化が目的なら、移動依頼を閉鎖(依頼リストがあったところにRFDへのリンクを設置)してRFDに一本化しませんか?
*(移動依頼){{RFD|伊藤亜由美|伊藤ゆみ}}
これなら依頼者も悩みようがありません。--Triglav会話) 2017年5月14日 (日) 21:17 (UTC) 取り消し--Triglav会話2017年5月19日 (金) 02:39 (UTC)[返信]
コメント それなら、移動依頼でRFDで扱える案件を受付除外したほうが早いです。ただでさえ、RFDで履歴統合を扱っているのですから、これに移動依頼案件まで追加したら、正直見通しが良くないでしょう。移動依頼はNC違反の移動も扱う「移動機能」を補助する依頼で、RFDはリダイレクトを削除する「削除機能」を行使する依頼ですから、移動依頼までRFDで扱うのはちょっと違うと思います。ぶっちゃけ「移動の妨げになるからリダイレクトを削除して」という依頼と、「移動先がリダイレクトだけだけど、移動先の削除が必要だから移動をしてください」という依頼はそれぞれで対応しちゃ何かまずいでしょうか。RFDで出されたら「削除」すればいいし、移動依頼で出されたら「移動」すればよいでしょう。ただ、移動までやるべき案件はできるだけ移動依頼へ送ってねと注意を促す、それじゃだめですか?--アルトクール会話2017年5月17日 (水) 10:26 (UTC)[返信]
コメント 管理者・削除者ではない利用者の立場からすれば、依頼提出先が複数ある状態よりかは、文書類で一意性を明示してあった方が助かります。「あっちでもいいです。こっちでもいいです。」のような曖昧さを残さない方が混乱の元とならず、良いと思います(初心者が依頼提出先を学ぶ際のことも考慮してです)。もっとも依頼場所誤りがあったときの対応として、依頼提出の初心者が誤って提出した依頼の代理提出を行うとかのフォローはあってしかりでしょうけど。--Don-hide会話2017年5月17日 (水) 13:35 (UTC)[返信]
コメント なら、Triglavさんの言う通り、RFDに一本化して移動依頼そのものを廃止しましょう。移動依頼で扱う案件のうち「どうしても管理者などの上級権限を持っている人でなければできずRFDの対象外」というのはファイル名前空間の移動と、保護されたページの移動です。この二つについては基本的にWikipedia:管理者伝言板/その他の伝言で扱い、白紙保護されたページへの移動についてはWikipedia:保護解除依頼で扱います。ただ、依頼ページに「削除」「移動」「統合」を扱えば見通しが悪くなりますから、原則「削除」と「統合」を扱って、「移動」は利用者に任せる(WP:CRD#削除依頼における議論による削除のみ、ただし管理者による移動も「妨げない」)とすればどうですか。--アルトクール会話2017年5月17日 (水) 14:09 (UTC)[返信]
コメント ファイルに保護ページですか。移動依頼を全廃というわけにはいかないのですね。ならば、こちらの文言は「移動依頼に提出してください」として、仮に提出された場合は「依頼文を移動依頼へ転記してください」とでもして詳しい方に転記してもらうのはいかがでしょう?--Triglav会話2017年5月17日 (水) 19:56 (UTC)[返信]
コメント あとは頻度ですね。保護中の依頼は保護編集依頼で処置できるとして、日本語版ローカルのファイルの改名がどれくらいあるか? --Triglav会話2017年5月18日 (木) 00:50 (UTC)[返信]
コメント 統計を取ったわけではありませんが、移動依頼で扱う案件のうち多い順で「改名合意に伴うリダイレクト削除のある移動」「即時改名を理由としたリダイレクト削除のある移動」「NC違反・差し戻し」「履歴の入れ替え」「保護されたページ関係の移動」「ファイルの移動」でしょう。ファイルと保護ページは体感としてはそれほど多くない(3か月に1回みるかどうか)です。ファイルはローカルへのアップ自体がコモンズへのアップよりも圧倒的に少なく、仮に名前を付け間違ったら「新しい名前でアップロードして旧名は即時削除(WP:CSD#ファイル9もしくはWP:CSD#ファイル3)」という措置を取る方が多いので、あまり見かけません。直近でファイルの移動を行ったものについてもアップロードする利用者がファイル名前空間で移動ができるということを知らない可能性もあるんですが。保護は先日も「ノートに作られた記事を白紙保護された標準名前空間へ移動するのに解除を」ということで保護解除依頼が出されて対応しました。移動を伴うような案件なら、管理者が都度判断して移動するなり、解除だけするなりすれば余計な面倒を起こさないと考えられます。あと、思い出したのが「履歴入替」ですね。これも、仮に移動依頼が廃止したときは管理者伝言板で対応できるレベルで頻度は少ないです。--アルトクール会話2017年5月18日 (木) 01:19 (UTC)[返信]
コメント 移動依頼の全面廃止が出来ないとなれば、もっとシンプルに、現行の依頼場所はいらうことなく、移動依頼で現状扱っている案件はリダイレクトの削除依頼では今後扱わないように、文面修正するのではだめでしょうか。移動依頼を廃止しようとしても例外が残るのであれば、こちらのほうが依頼場所指定にかかる文面修正だけで済みますし、いかがでしょうか。--Don-hide会話2017年5月18日 (木) 01:53 (UTC)[返信]

ここの議論を知らずにWikipedia:井戸端/subj/移動依頼の「依頼できるもの」の文言についてを提起してしまった者です。そこでWikipedia:即時削除の方針#技術的理由による削除の存在が指摘されましたが、それを見る限り、現状でも首記のような案件では移動依頼への提出が推奨されているようですので、普通に考えれば、現状移動依頼で扱っている案件をリダイレクトの削除依頼で扱わないように文面修正するのが自然な流れだと思います。移動依頼の廃止も検討されているようですが、他言語版との整合性を考えると移動依頼の廃止には賛成できません。わざわざ他言語版と異なる方向に修正する必要はないと思います。--新幹線会話2017年5月18日 (木) 05:38 (UTC)[返信]

コメント 「現状移動依頼で扱っている案件をリダイレクトの削除依頼で扱わないように文面修正するのが自然な流れである」「移動依頼を廃止すべきではない」との点、おっしゃる通りだろうと思います。--Don-hide会話2017年5月18日 (木) 08:16 (UTC)[返信]
コメント 他言語に沿う必要はありませんが、他所に振り分けられないケースが1件でもあれば、移動依頼は残しておいたほうがよいです。--Triglav会話2017年5月19日 (金) 02:39 (UTC)[返信]
コメント どちらかというと移動依頼自体が特殊な立場で、「リダイレクトの削除依頼」「保護解除依頼」「その他の移動補助の依頼」を扱っているものなので、それぞれを本来の依頼先(リダイレクト関係はリダイレクトの削除依頼、保護ページ関係は保護解除依頼、そのほかは管理者伝言板/その他の伝言)へ振り分ければ、「移動依頼」というものは不要です。管理者伝言板への振り分けを認めないという理由がなければ、振り分けられないケースというのは存在しないことになります。--アルトクール会話2017年5月23日 (火) 14:09 (UTC)[返信]

方向性アンケート

意見も出尽くしているため、申し訳ないんですが方向性アンケートをお聞きします。移動依頼をリダイレクトの削除依頼へ統合するのは無理があるのでその点だけは(履歴入れ替えやファイルの移動などがあるため)除外します。期限は本日より現時点(2017年6月25日 (日) 18:39 (UTC))から1週間とします。一人一つまででご意見をお寄せください。ほぼ同一の方向性がまとまっていれば、それを反映する場合があります。

  1. 現状を維持する(改定無しでしばらく様子を見る)
  2. 「改名提案を伴う移動先のリダイレクトの削除」を移動依頼で受付することを推奨とする。(このセクションの原案通り)
  3. 移動依頼でRFDに関わる部分の受付を除外し、リダイレクトの関わるものはリダイレクトの削除依頼を推奨とする。(リダイレクト2版などの移動依頼をRFDへ振り当て、「移動」で対処をしないこととする)
  4. 移動依頼で対応できる案件をRFDで受付除外する。(RFDに依頼された場合は依頼場所違いとして却下する)
  5. 移動依頼を廃止し、現状の受付しているものを「リダイレクトの削除依頼」「保護解除依頼」「その他の移動補助の依頼(管理者伝言板/その他の伝言)」へ振り分ける。(移動依頼の完全廃止)
  6. 1から5までになく、その他の意見がある。
  • コメント 2番 これがおそらく一番負担が少ないと思われます。移動依頼を廃止して、それぞれに振り当ててもいいのですが、結局、リダイレクト削除→移動では手間がかかるだけということもあるので。--アルトクール会話2017年6月25日 (日) 18:40‎ (UTC)[返信]
  • コメント 4 過去にもリダイレクトの削除依頼でも他の依頼でも依頼可能な案件があったものの、それはリダイレクトの削除依頼では依頼場所誤りとするよう運用改定がされましたが、それとの整合性を考えるなら、依頼提出場所を一意にしておくことが、初心者にも明瞭な運用になると思います。もっとも依頼場所誤りに気づくならば、よほど時間のとれない場合出ない限り、単に即時存続票を投じておしまいではなく、正しい依頼場所に代理提出することも推奨したいと思います。--Don-hide会話2017年6月26日 (月) 01:03 (UTC)[返信]
  • コメント 期間内に意見が集まっていなかったため、本日よりさらに意見を求めることとします。今回は、この議論に参加していてかつアンケートに答えていない方へ参加を呼びかけます。目安は1週間としておきます。--アルトクール会話2017年7月31日 (月) 11:40 (UTC)[返信]
  • (回答)2 番。かねてコメントしたとおり「推奨」が妥当だと考えます。--Kurihaya会話2017年8月1日 (火) 03:25 (UTC)[返信]

アンケートも周知も十分に行ったと判断します。そのうえで、今回は2番の「「改名提案を伴う移動先のリダイレクトの削除」を移動依頼で受付することを推奨とする。(このセクションの原案通り)」方向としますがよろしいでしょうか。移動依頼で対応できる案件をRFDで受付除外するのは労力に見合わない(依頼推奨場所を見て、それでも頑なにリダイレクトの削除依頼を出す人がいるでしょうか)と考えられる、初心者であっても「依頼提出時点で目を通しておく部分でケースによって異なる依頼場所についてはっきり書いておく」というのが一応まとめです。「推奨」でよいとする意見のほうが多いと判断しましたが、他に意見はありませんか。なければ「推奨」の形で依頼ページ関連を修正していきます。--アルトクール会話2017年9月7日 (木) 16:39 (UTC)[返信]

条件付賛成 「利用者ページまたはその配下のページ」かつ「リダイレクトページ」の削除依頼提出場所がWikipedia:利用者ページの削除依頼のみに限定されています(推奨ではなく、提出先が限定されています)。それとの整合性をとるのであれば、すなわち、「移動依頼で対応できる案件をRFDで受付除外しない」のであれば、『「利用者ページまたはその配下のページ」かつ「リダイレクトページ」の削除依頼提出場所について、Wikipedia:利用者ページの削除依頼を推奨するが、Wikipedia:リダイレクトの削除依頼/受付に提出したとしても依頼場所誤りとはしない」』とし、整合性をとるべきと考えます。この整合性がとれない状態での「推奨」改訂には反対いたします。--Don-hide会話2017年9月8日 (金) 03:48 (UTC)[返信]
コメント なぜそこまで頑ななんでしょうか。利用者名前空間についてははっきりと提出場所が決まっていて分離しているわけでですが、それをわざわざRFDでも扱えるようにする必要性を私は見出せません。それならば、専用依頼ページで対応している利用者名前空間の削除関連自体を廃止して、削除依頼/リダイレクトの削除依頼/移動依頼に振り分ければ済む話になります。その点はどうお考えでしょうか。わざわざ分離させたものを「こっちでも扱えるよ」と案内しなければならないメリットを教えてくれませんか。利用者名前空間は専用ページがあるからそっちで扱いましょうって話を根本から崩すだけの理由を説明してください。--アルトクール会話2017年11月30日 (木) 11:19 (UTC)[返信]
コメント 利用者ページ(その配下のページも含む。)かつリダイレクトページの場合、以前は利用者ページの削除依頼でもリダイレクトの削除依頼でもどちらでも好きな方に提出することが(規定上は)できる状態でした。それを一本化したのは当方ですから、無理にそれを以前の形に戻したいとは思いません。しかしながら、リダイレクトの削除依頼で扱える案件かつ移動依頼で扱える案件について、どちらでも扱えるとなっているものを一元化しないとなるならば、当方が以前関わった利用者ページ(その配下のページも含む。)かつリダイレクトページの依頼提出先の一元化との整合性がつきません。ですので、「利用者ページ(その配下のページも含む。)かつリダイレクトページの依頼提出先」・「リダイレクトの削除依頼で扱える案件かつ移動依頼で扱える案件の依頼提出先」の間で一元化するものとしないものとの混在が起きたままというのは問題があるわけです。「リダイレクトの削除依頼で扱える案件かつ移動依頼で扱える案件の依頼提出先」について一元化を行わない(推奨レベルにとどめる)のであれば、「利用者ページ(その配下のページも含む。)かつリダイレクトページの依頼提出先」についても一元化したものを解かないといけないのではないでしょうか。過去にも述べましたが、提出先の一元化は特に初心者にとって提出先にかかる混乱を抑えることができるにもかかわらず、「リダイレクトの削除依頼で扱える案件かつ移動依頼で扱える案件の依頼提出先」について一元化を行わないという意見が大勢を占めるのならば、先に述べた整合性の観点から、「利用者ページ(その配下のページも含む。)かつリダイレクトページの依頼提出先」についても、不本意ながら一元化したものを解かざるをえないと考えます。一元化すべきものが2つあり、一方だけそうであり、他方がそうではないという不整合は正直どうなんだろうと考えます。個人的には一元化すべきものは一元化対応で良いというスタンスなのですが。--Don-hide会話2017年11月30日 (木) 12:24 (UTC)[返信]
コメント いや、名前空間で区切って専用にしているページをわざわざ「推奨」などと付けて受け付けれるようにするんですか?それじゃ、UFDの存在意義がないじゃないですか。利用者名前空間は一括してUFDで扱うようにするのと、RMとRFDは両方扱えるようにするのとだとそもそもの前提条件が違います(というか、RFD案件ではなくRM案件の利用者名前空間の話であれば、RMで受付を除外してませんし)。前者は「名前空間で専用依頼ページ」であるのに対して、後者は「管理者の権限を行使するための汎用の依頼申請ページ」です。RMとRFDのどちらでもいいって話をしているのは、前提として「管理者が削除の権限だけを行使する」、つまり管理者に削除だけ依頼するか、「管理者に移動まで面倒見てもらう」依頼かの違いです。そこに「RM案件だから」でRFDで除外する理由はありません。UFDに依頼を集約したのとは今回の明文化はそもそもの意味が違います。一元化にそこまでこだわるなら、RMもUFDも廃止して、既存の別の依頼ページに集約したほうがいいでしょうとは以前話をしています(2017年5月23日 (火) 14:09 (UTC)の私のコメントをご覧ください)。--アルトクール会話2017年11月30日 (木) 14:04 (UTC)[返信]

コメント 結局のところ、実際の管理業務の中では「完全禁止では煩雑さが増す」と考えられるものといえます。結局、移動依頼を廃止するような一元化は現状では無理で、移動依頼とリダイレクトの削除依頼で重複している依頼については「どちらかを推奨とする」のに留めるのが良いという結論であると判断します。あと数日中に文章を改訂します。--アルトクール会話2018年3月30日 (金) 03:18 (UTC)[返信]

過剰なリダイレクト削除について

WP:Rによれば旧字体や外国語表記はリダイレクトの作成対象となっています。それなのに、現状は旧字体や外国語表記のリダイレクトは必要性が低いと削除されています。これはWP:Rの有名無実化に繋がるため、よくないのではないでしょうか?過剰な削除はやめるべきです。そうでなければWP:Rを改定するのも手でしょう。--2001:240:2418:50C3:620E:5B18:20AE:FE0F 2018年3月31日 (土) 12:07 (UTC)[返信]

  • コメント ケースバイケースです。旧字体が許容されるのはその使用が確認されるものです。国立市國立市ではリダイレクトを作成しません。外国語の表記の許容も「日本語として」使われている場合であって、すべてをリダイレクトの作成で許容しているわけではありません。--アルトクール会話2018年3月31日 (土) 12:11 (UTC)[返信]
返信 国立市は戦後にできた街ですからリダイレクトの必要性は低いでしょう。ですが、戦後に作られた言葉でない一般名詞に対するリダイレクトが削除された例がいくつもあります。残しておいて困らない物は残置していいのでは?--2001:240:2418:50C3:620E:5B18:20AE:FE0F 2018年3月31日 (土) 12:14 (UTC)[返信]
コメント 例を挙げてくれませんか。RFDで扱う案件は非常に多いため「そのようなものがある」とだけでは議論になりません。--アルトクール会話2018年3月31日 (土) 12:18 (UTC)[返信]

Template:AFDを用いた投票

Template:リダイレクトの削除依頼にて、「Template:AFDの使用を認める方針は現状はありません。」との記載が2018年2月7日及び2018年3月3日の編集で導入されておりますが、アイコンを使用した投票は既に広く行われており、デファクトスタンダードになっているとも言えます。この文言を導入したVigorous action氏は要約欄に記載した「方針文章との乖離を修正」を図ったものと思いますが、アイコン利用は視認性の上でも効果が高く、取り立ててデメリットもないことから、方針文章自体が実情にそぐわない(もしくは、実情に追い付いていない)のではないでしょうか。Wikipedia:削除依頼#依頼への投票・コメント方法でもアイコンの使用が認められており、また2月7日以前の履歴ではTemplate:AFDの使用が認められているように思われます。Vigorous action氏は既に投稿ブロックされたようですし、問題なければ従前の通りアイコンの使用を認め、またWikipedia:リダイレクトの削除依頼でも上記の削除依頼に準じた形でアイコンでの投票について言及する形に改めたいと思いますが、いかがでしょうか。なお、アイコン形式に統一するという意図はなく、どちらでもよい、という形にしたいと考えます。--Suz-b会話2018年5月23日 (水) 15:44 (UTC)[返信]

  • 賛成 Vigorous actionさんの当該編集はノート等での合意のもと行われたわけではありません。当該記載ですが、(1)方針に{{AFD}}の使用の可否についての規定自体がない と言いたいのか、(2)方針として{{AFD}}の使用は認められていない と言いたいのかにもよると思います。私は前者(1)と思いますが、コミュニティとの齟齬がないか確認したいです。さて私の意見ですが、アイコンの使用を敢えて禁じる必要性も特に思いつきません。アイコンの使用を強制する必要はありませんが、{{AFD}}の使用も可能と明記してよいものと思います。--郊外生活会話2018年5月23日 (水) 16:11 (UTC)[返信]
  • 賛成 Vigorous action氏による規約の編集は、現行ルールを明確にしただけに過ぎないため特に問題はありませんし、本件が原因によるブロック処置ではないので、ブロックについての説明があることに違和感を感じますが、事例を積み重ねて正式採用することは、ごく普通の作業の流れですので「どちらでも可とする」に賛成します(履歴が追えなかったのですが、たしか他者の投票をテキストからAFDに書き換える行為を目撃してルールを徹底させたのではないでしょうか?)。--Triglav会話2018年5月23日 (水) 17:04 (UTC)[返信]

カテゴリの移動跡地リダイレクト

WP:RFD/R#RFDCategory:BCリエトゥヴォス・リータスの選手で指摘がありました。現行のルールではWikipedia:リダイレクトの削除依頼の冒頭に「リダイレクト化されたカテゴリページの削除は扱いません。カテゴリの履歴がリダイレクトのみである場合は即時削除へ、カテゴリにリダイレクトではない履歴がある場合は通常の削除依頼へ提出してください。 」とあり、移動跡地のリダイレクトをRFDで扱えないようになっていますが、この文言は記事同様の移動が可能になった2014年以前のものであるため、現状にそぐわない可能性があります。

--Triglav会話2019年6月18日 (火) 14:28 (UTC)[返信]

カテゴリ条項撤廃の提案

それでは、カテゴリに関する特別な条項を排除して記事と変わりなく手続きができるようにします。

  • (現)リダイレクト化されたカテゴリページの削除は扱いません。カテゴリの履歴がリダイレクトのみである場合は即時削除へ、カテゴリにリダイレクトではない履歴がある場合は通常の削除依頼へ提出してください。
  • (改)リダイレクト化されたカテゴリページの削除は扱いません。カテゴリの履歴がリダイレクトのみである場合は即時削除へ、カテゴリにリダイレクトではない履歴がある場合は通常の削除依頼へ提出してください。 2014年よりカテゴリページは記事同様の移動処理による改名が可能になりました。
  • (現) 通常記事・カテゴリ・履歴のあるリダイレクトの削除依頼は → 削除依頼へ。
  • (改) 通常記事・履歴のあるリダイレクトの削除依頼は → 削除依頼へ。

取り消し線としての掲載期間は1年間とします。--Triglav会話2019年6月28日 (金) 14:27 (UTC)[返信]

報告 改定しました。--Triglav会話2019年7月15日 (月) 13:23 (UTC)[返信]

AFDのB-2問題に関連するリダイレクトの削除依頼は、通常のAFDに回付すべきように、RFD方針を変更動議

(動議内容)削除依頼でのプライバシー侵害(B-2問題)に関連するリダイレクトは、リダイレクトの削除依頼ではなく、通常の削除依頼(削除依頼サブページ作成)に回付すべきように、リダイレクトの削除依頼の方針(ここの本文)を変更する動議を提出します。--Kyuri1449会話2020年12月6日 (日) 05:06 (UTC)[返信]

(理由)プライバシー侵害(B-2問題)では、往々にして議論途中に新たなプライバシーの暴露が行われてしまい、よってAFD関連ページのB-2(版指定)削除さえ必要となるケースがあります。さて、Wikipedia:削除依頼/Wikipedia:リダイレクトの削除依頼/受付において見られるように、それがリダイレクトの削除依頼ページ(ここの本文)において発生してしまった場合、ここの本文の極めて多数版の秘匿が必要となるケースの可能性が危惧されるため、それは本来のRFD議論の透明性確保の障害となりうるためです。AFDにてサブページ削除方式に移行してしまえば、サブページ等に問題は限定されます。そもそもプライバシー問題は、一般的なRFDのように単純な本文空間上の処置問題には止まらず、複雑な議論として紛糾しがちのため、その意味でもAFD回付が適当とも考えられます。--Kyuri1449会話2020年12月6日 (日) 05:06 (UTC)[返信]

(依頼内容)まずは、動議内容の可否について議論をお願いいたします。動議が可となった場合においてのみ、リダイレクト削除依頼ページ本文の変更内容検討動議を追って提出予定です。--Kyuri1449会話2020年12月6日 (日) 05:06 (UTC)[返信]

  • コメント ご指摘の件の他にも、RfDではCategory:緊急案件がつけられない点もありますので、現状の方法がベストとは考えていませんが、しかし方法を変えた場合、リダイレクトページそのものに問題がある場合に、そのページ名でAfDサブページがつくられてしまうリスクというのもあります(実際にAfDでもサブページ名に一般人名を入れる事例など時々あります)。その点も考慮が必要ではないかとは考えました。--郊外生活会話2020年12月10日 (木) 10:45 (UTC)[返信]

新規利用者の投票資格を制限する提案

議論の取り下げに伴う。--Y-route会話2023年1月22日 (日) 15:21 (UTC)[返信]

現在、通常の削除依頼における投票資格は「依頼開始時点で編集回数が50回"以上"の登録利用者」であるのに対し、リダイレクトの削除依頼では「登録利用者」であることのみ、とされています({{AFD}}もそのように対応しています)。

しかし、なぜこのような大きな差が設けられているのか分かりません。投票資格のないIP利用者が、簡単な手順でアカウントを作るだけで即座に資格を得られるのです。多重投票のたやすいIP利用者が投票できないのは分かりますが、これでは同じような手順(例:接続先を変えてそれぞれで登録する)で容易に別人を装えるため、対策としては弱過ぎると思います。

加えてこれまで、新規利用者が駆け込みで投票し書式崩れやミスが生じたり、ソックパペットと思しき新規利用者が不適切な理由を付して投票する事例も何度かみられており、これらを少しでも防ぐためには、登録利用者に対してもある程度の投票資格制限を設けるべきではないでしょうか。

個人的な意見としては、統一の観点から削除依頼と同じく「依頼開始時点で編集回数が50回"以上"の登録利用者」とするのが妥当と考えています。リダイレクトの削除依頼自体が削除依頼を簡略化した議論の場であるため、という考え方もできなくはありませんが、それでも今の制限はあまりに緩過ぎますし、投票という行為に変わりはないため、引き上げは必要だと思います。

移行措置については、変更施行日時までの投票は施行後も有効、意見変更や撤回も(クローズまでは)認める、という形を考えています。--Y-route会話2022年1月20日 (木) 10:42 (UTC)[返信]

  • 賛成 自分も以前から気になっていた点ではあったので、賛成票を入れておきます。現状のルールではソックパペットが投票しやすい環境となっており、公平性を保つことが難しいです。それこそ、自分もソックパペットが複数いる依頼を何度も見かけたこともあり、ソックパペットに半ば押し切られる形で存続票を入れる人も多々います(いずれにしても、議論は荒れやすい傾向にあります)。そのため、多重投票への対策として、通常の削除依頼と同じ基準を持ち込むことには賛成です。ただ、何かしらの特別な理由をもとに制度が存続されているのであれば、少し考え直します。--NatsuQuiz会話2022年1月24日 (月) 07:13 (UTC)[返信]
  • 賛成 WP:RFD/Rは過去にLTA:SNKWのソックパペットが現れたりもしているので、賛成です。ただ、リダイレクトの削除依頼はケースABCDEFGZが分かっていなくてもある程度の議論はできる気がするので、少しきつすぎるという意見はあるかもしれないと感じました。なお、今回の件もソックパペット絡みなので、代替案としては議論合意の上無期限半保護などもありえるのかと思いましたが、そうするとIP・新規ユーザーが依頼を出せなくなるのでそれでは困るか、などと考えていました。簡単ながらコメントいたします。--Dragoniez (talk) 2022年1月25日 (火) 19:09 (UTC)[返信]
  • 取り下げ 議論提起以来コメントできず申し訳ございませんが、一旦本議論を取り下げとさせてください。複数の賛成票もある中ですが、指摘にもある通りコメント依頼等への告知ができず瑕疵のある提案となっていたこと(手が回りませんでした)、議論開始から1年経過したことによる状況変化もあり、継続するにしても仕切り直す必要があると判断したためです。今後、同じ内容での再提案は妨げません。
    実はこの議論は、RFDでしばしば編集数の少ないアカウント(jawp以外で作成している点やアカウント名の特徴的な傾向から同一人物とも推定。なおLTA:HEATHROWとは別です)が、方針に合致しない理由で存続票を入れるケースがしばしば見られたことにより、対策の一環として提起したものでしたが、この議論中に当該アカウントの1つが無期限ブロックされ、以降はほとんど再発しなくなったというのも一因にあります。とはいえ活動を休止したとは言い切れないため、状況によりいつでもこの議論が復活する可能性はあるでしょう(もっともこれは対策としては副次的なもので、根本的対策は別にすることになりますが)。--Y-route会話2023年1月22日 (日) 15:21 (UTC)[返信]

{{もしかして}}の依頼場所について

Wikipedia:削除依頼/ペレゼン地球をみて思ったのですが、{{もしかして}}のページに削除依頼を提出する場合、依頼場所はどこが適切になるのでしょうか。少々調べてみたところ、Template‐ノート:もしかして#運用についてにて「『もしかして方式』の誘導ページはリダイレクトやソフトリダイレクトとは別物とみなす。」という運営方針に関する「提案」があり、Wikipedia:リダイレクトの削除依頼/2021年8月にはこれを理由に、削除が依頼されたもしかしてページが即時存続扱いになっているものが過去にある一方、もしかしてページに付与されるCategory:誤表記Category:リダイレクトのサブカテゴリで、混乱を招く状況にあるのではないかと思いました。前から思ってはいたのですが、Help:ソフトリダイレクト#削除における「ソフトリダイレクトはAFDではなくRFDとして削除依頼する」ということを、Wikipedia:削除の方針およびWikipedia:リダイレクト削除の方針にも明記しておいた方が良いように個人的に思い、もしかしてページに関してもどこで依頼をすべきなのかを方針ページに明記しておいた方が良いのではないでしょうか。--Dragoniez (talk) 2022年5月5日 (木) 07:07 (UTC)[返信]

LTAによる依頼投票コメント資格変更の提案

LTA:HEATHROWによる荒らし(マッチポンプ依頼)が多発しているため、「長期に亘り荒らし行為に及んでいることが明らかな利用者又は投稿記録の大部分を荒らし行為が占める利用者」(WP:CSRDより表現を引用)の依頼、投票、コメントを無効にする提案をします。

依頼 投票 コメント
登録利用者副アカウントを除く) ○(可) ○(可) ○(可)
IP利用者 ○(可) ×(不可) ○(可)
LTA ×(不可) ×(不可) ×(不可)

表を上記に変更することを提案します。--柏尾菓子会話) 2022年12月1日 (木) 07:53 (UTC) 下線部を追加し、LTAのみに変更。--柏尾菓子会話2022年12月1日 (木) 07:59 (UTC)[返信]

反対 コメント 「登録利用者(副アカウントを除く)」とあり、副アカウントでの依頼や投票が無効になるのは明白です。実際Wikipedia:削除の方針#参加資格では副アカウントでの依頼、投票、コメントは不可となっています。LTAのソックパペットはもちろん副アカウントに含まれますから、完全に重複していて、LTAにエサを与えるだけなのは明確なので不要です。--どうなる?会話) 2022年12月2日 (金) 06:39 (UTC)変更--どうなる?会話2022年12月2日 (金) 10:02 (UTC)[返信]
@どうなる?:さん Wikipedia:リダイレクトの削除依頼/受付をご覧いただければわかるのですが、わざわざこんなことを主張して(差分)投票されました。多重投票ではなく、登録利用者のため、この投票は無効になっていません。雲頂温度の依頼(差分)やキャサリーン台風差分)のマッチポンプ依頼も、現在の資格では登録利用者による依頼なので有効となっています。副アカウントを除く、とありますが、副アカウントは不可、とは書いていないため、そこの穴をつかれていると考えています。--柏尾菓子会話2022年12月2日 (金) 07:00 (UTC)[返信]
では、副アカウントによる投票やコメントは禁止すればよいです。LTAのみを禁止してはLTAではない荒らし利用者(WP:VIPなど)には適用されないので、このようにしてはどうでしょうか。
依頼 投票 コメント
登録利用者副アカウントを除く) ○(可) ○(可) ○(可)
IP利用者 ○(可) ×(不可) ○(可)
登録利用者の副アカウント(適正な多重アカウント使用は登録利用者に準ずる) ×(不可) ×(不可) ×(不可)
--どうなる?会話2022年12月2日 (金) 09:55 (UTC)[返信]
(賛成)よい案をどうもありがとうございます。「LTAのみを禁止してはLTAではない荒らし利用者(WP:VIPなど)には適用されない」に納得したため、変更に賛成します。--柏尾菓子会話2022年12月2日 (金) 11:55 (UTC)[返信]
これは余計ですが、初投稿がこのノートページの利用者の発言が善意から来ているのかについては、それこそ疑問符が付くでしょう。--Sethemhat会話2022年12月2日 (金) 12:18 (UTC)[返信]
情報 User:どうなる? はLTA:HEATHROWまたはその模倣としてブロックされました(Logid/6241665)。--郊外生活会話2022年12月4日 (日) 01:31 (UTC)[返信]
  • コメント 少なくとも、単にLTA:HEATHROWが依頼しただけであればブロック時にWP:SK#3-3で即時存続させるという選択肢はとれると思います(WP:SK#3-3相当で依頼自体を除去でも問題ないと思います)。LTAのブロック破りはWP:SOCK#副アカウントの不適切な使用(多重アカウント使用が禁止される行為)ですから、即時存続させることが現行の投票規定と矛盾することはないと思います。真に削除されるべきページであれば、LTA以外の他の誰かが依頼すると思いますし、直近の依頼でHEATHROWによる依頼・コメントに賛同しているLTA以外の人が同様の依頼・コメント等をしたところでLTAとみなされることはまずないと思います。一方、即時存続は必須ではないので、依頼者はともかく依頼としてはまともと思えば即時存続させずに議論を続けさせても問題ないとは思います。「副アカウントを除く、とありますが、副アカウントは不可、とは書いていないため、そこの穴をつ」くというよりは、純粋な新規アカウントと偽って参加しているのだと思います(HEATHROWが初投稿からLTAの典型的な行動をとっているときもありますが、管理者伝言板に報告されてから明らかにLTAの典型的な行動をとりはじめることも少なくありません。また、改名提案などソックパペットの意見表明が無効化されると明確に書かれているところでも出現しているような系統ですから)。通常の削除依頼にもHEATHROWは出てきますし、通常の削除依頼でブロック破りで依頼・投票・コメントを行っても必ずしも無効化できるとは限らないので、LTA(あるいは副アカウント)は無効と明記したければ特に反対するつもりもありませんが、明記したところで有効な解決法としてはあまり期待できないようには思いました。--郊外生活会話2022年12月3日 (土) 06:00 (UTC)[返信]
    • @郊外生活さん ご意見どうもありがとうございます。LTA:HEATHROWについては納得しました。それ以外を想定した際、即時存続させた場合に、不可(無効)と明記がなければごねる意見が出ることも想定して(LTA:HAASENあたりを想定しています)、コミュニティの疲弊を減らすために、明記するという提案は取り下げないことにします。どうなる?さんはブロックされましたが、LTA以外にも適用できた方がよいのではないかと考え、現時点では登録利用者の副アカウントの案がよいと考えています。--柏尾菓子会話2022年12月4日 (日) 02:14 (UTC)[返信]
  • コメント 上記の郊外生活さんの考え方でよいかと思います。もし明文化するならば、Wikipedia:削除の方針#参加資格Wikipedia:利用者ページの削除依頼#参加資格と統一するのはどうでしょうか?--113.197.145.128 2022年12月5日 (月) 12:13 (UTC)[返信]
    • @113.197.145.128さん ご意見どうもありがとうございます。Wikipedia:削除の方針#参加資格、Wikipedia:利用者ページの削除依頼#参加資格と統一すると、編集回数50回の制限が加わることになりますが、上の方(#新規利用者の投票資格を制限する提案)の提案で健ちゃんさんのコメント「それぞれの投票者が投票資格を満たしているかどうかを確認する手間が増えることに見合うだけのメリットがあるといえる」(特別:差分/90698395より引用)か、に納得したため、回数制限を設けない方がよいのではないかと考えます。副アカウントか否かは、ブロックされているか否かを確認する程度ならば、手間がかからないと考えます。--柏尾菓子会話2022年12月5日 (月) 12:26 (UTC)[返信]
  • (反対)LTA は jawp の決まりごとを意図的に守らない人ですから、この参加条件を追加しても依頼不備案件になるだけで、依頼編集を止める効果は薄いでしょう。もし有害なリダイレクトを LTA が依頼した際に、即時存続とすべしとなるとよろしくありません。誰が依頼してきたものか気にせずに処理する現状でなにかお困りでしょうか。--Kurihaya会話2022年12月6日 (火) 04:33 (UTC)[返信]
  • 終了 議論開始から1ヶ月以上経過しましたが、反対意見のみですので、この方針変更提案は無効・却下となります。パラソウル会話2023年1月22日 (日) 06:09 (UTC)[返信]
  • 情報 利用者:パラソウル会話 / 投稿記録 / 記録LTA:HEATHROWとしてブロックされました。よって議論は続行して下さい。--レキセント会話2023年1月22日 (日) 07:13 (UTC)[返信]

リダイレクトの削除依頼でのWP:SK#3-3の適用について

即時存続を確認したところ、これは削除依頼における方針であり、リダイレクトの削除依頼でも適用、とは記述がありません。リダイレクト削除の方針を確認したところ、依頼者以外の賛否なしで終了可能なものとして、即時存続に関する記述がありません。リダイレクトの削除依頼でWP:SK#3-3を適用してもよいのでしょうか。LTAなどによる依頼で即時存続票がついていても、審議期間を経て存続で終了しているのは見かけますが、WP:SK#3-3により即時存続で終了されるのを見たことがないので、疑問に思いました。よろしくお願いします。--柏尾菓子会話2022年12月14日 (水) 05:43 (UTC)[返信]