Wikipedia‐ノート:削除者/ログ1

ナビゲーションに移動 検索に移動

これまでの議論とこれからの予定[編集]

これまでの議論:Wikipedia:井戸端/subj/新しい利用者グループの作成

これからの予定

  1. 基本的な運用案の決定
    1. 削除権限以外の関係するケース
    2. 対処範囲の決定
    3. その他
  2. 権限付与ルールの決定

機能割り当て案2

  • ページを削除 (delete)
  • ページを一括削除 (nuke)
  • ページを復元 (undelete)
  • 削除された履歴項目 (関連する本文を除く) を閲覧 (deletedhistory)
  • 削除された本文と削除された版間の差分を閲覧 (deletedtext)
  • 削除されたページを検索 (browsearchive)
  • ページの特定の版を削除/復元 (deleterevision)
  • 転送ページを作成せずにページを移動 (suppressredirect)
  • 速度制限を受けない (noratelimit)

コメント ある程度決まった内容を案2としてまとめます。--Marine-Blue [ 会話 履歴 電信 ] 2011年3月1日 (火) 14:17 (UTC)

コメント 同時に提案されてます3点に共通する話題でしたのでWikipedia:井戸端/subj/新しい利用者グループの作成の方で書かせていただきましたが[1]IPブロック適用除外については人数が多くなることを想定すると、入れることはかなり危険だと思われます。ですのでその点のみ削った方が良いだろうと思います。そのほかは賛成です。--Was a bee 2011年3月2日 (水) 11:50 (UTC)
Wikipedia:井戸端/subj/新しい利用者グループの作成Wikipedia‐ノート:巻き戻し者の議論を踏まえたものですが、特におかしい所がないようであれば、しばらくしましたら、上の機能割り当て案2からipblock-exemptだけ除く形で小さい変更として反映させようかと思います。--Was a bee 2011年4月3日 (日) 16:12 (UTC)
報告 上記の点、対応しました。--Was a bee 2011年4月14日 (木) 14:15 (UTC)

運用案[編集]

対処する依頼などの範囲[編集]

基本的には即時削除と削除依頼の対応になるんじゃないかと思います。移動依頼も対処していいのでしょうか。

なお、たたき台と言うことで「削除関係では管理者と同等に振る舞える」と簡単に書きましたが、これについては深く詰めていくべきだと考えています。--Marine-Blue [ 会話 履歴 電信 ] 2011年3月1日 (火) 14:17 (UTC)

コメント 移動依頼は対処する範囲に入れなくてよいと思います、それほどひっ迫しているものでもありませんし、むしろ即時削除および通常削除(削除依頼)の対応のみに範囲を限定した方が付与される側も付与に同意する側も動きやすいと思います。で、即時削除および通常削除での振る舞いですが、即時削除については管理者と同様に「基準に適合するか確認し、適合することが確認できた場合は削除を実行する」という方向で良いと思います。ただし「適合することを確認」の部分は時には難しい判断が必要なときもありますので、その辺りは無理せず慎重に(迷ったら対処しない)ということは必要だと思います(まぁ、これは管理者であっても同様ですけども)。削除依頼については私はあまり関わってないので賛否表明しかねますゆえ、どなたか削除依頼に対処している方のご意見を聞いた方がよいかと思います。--青子守歌会話/履歴 2011年3月2日 (水) 12:15 (UTC)
コメント 移動依頼も対処していいと思います。移動依頼に持ち込まれるものは合意形成がとれているのが前提なので、作業者の判断があまり必要とはされません。そういう意味合いでは、即時削除よりむしろ楽だと思います。もちろん、削除者の立候補の場所にはその旨書くことが必要だと思います。移動依頼は現在の管理者だけでも滞ることはあまりありませんが、あえて削除者を排除する必要もないのではないかと思います。--Jkr2255 (Talk/History) 2011年3月2日 (水) 13:07 (UTC)
コメント 削除者になろうと思っている方は多分、即時削除や削除依頼の滞りをみたりして「ちょっとでもお手伝いしよう」と思ってくれる方だと思いますので、そういう方に移動依頼といういわゆる「削除」とはちょっと違うところまで任せるというようにしてしまうと「削除系はいいけど、移動はよく分からないからなー」と思われて戸惑う人がいないか、それだったら別に無理して移動依頼を範囲に入れる必要もないだろうと思います。ただし、「やれること」と「やること」は違うので、移動依頼が分からなければ手を出さなければいいわけですし、おっしゃる通り「判断」をしなければならないことも少ない依頼ですから、含めておくことの実害はそれほどないでしょう。あとは「あってもいいからいれる」か「なくてもいいからいれない」のどっちにするかというところだと思います。--青子守歌会話/履歴 2011年3月2日 (水) 14:19 (UTC)

保護ページの扱い[編集]

保護関係の操作が出来ないため、対象のページが保護されていた場合はフォローが必要です。{{確認待ち}}のようなテンプレートを使用し、保護されたページを処理した場合は管理者へ保護を委ねる形で良いと思いますが、いかがでしょうか。削除依頼対象のページが保護されるケースは少ないため、既存のルールの応用で良いのではないか、と。--Marine-Blue [ 会話 履歴 電信 ] 2011年3月1日 (火) 14:17 (UTC)

コメント保護されているページについては対処しない」でいいんじゃないでしょうか。おっしゃるように保護されているページを削除しなければならない場合は稀ですし、そのような(保護されている=問題がさらに複雑そうな)少数のページは管理者に任せる方向性で問題ないでしょう。--青子守歌会話/履歴 2011年3月2日 (水) 12:15 (UTC)
コメント 保護されている案件については管理者のみの対応でいいと思います。実際、ページが保護されるほど問題がこじれた場合、ブロックや(半)保護といった、管理者しか持たない権限で対処する場合も多いし、そこまでもめる事例もそう多くはありません。「削除保護」というのはないので、全削除すべきものなら削除者でも問題はないと思いますが。--Jkr2255 (Talk/History) 2011年3月2日 (水) 12:58 (UTC)
コメント保護関係の操作が与えられていないと言う事で保護案件を外そうと言う話だと思いますが、保護されたページであっても全削除は可能であるようです。また現在削除依頼関係で保護されているページの多くは削除タグの剥離といった場合である(わたしで月に数件-十数件削除タグ剥離で保護している)と思いますので一定数の保護案件があるかと思います。その場合保護設定時に編集のみの保護(移動保護をつけない)設定にすると、保護関係の操作権限が無くても旧来の特定版削除の手法であれば技術的には可能ではないかと思います。さらに現在検討されております2段階半保護などの導入により高位の半保護とすることなどでも色々対応できる事がありそうな気がします。削除依頼サブページに{{確認待ち|保護}}のようにして、管理者が確認して保護関係の確認と必要であれば対処を行うなどの方法で色々回避できると思います。、--Vigorous actionTalk/History) 2011年8月2日 (火) 05:02 (UTC)

ケースB案件[編集]

Bellcricketさんが触れておられたことをなぞることになりますが、ケースB案件の問題が一番問題かもしれません。削除者は管理者よりも権限付与のハードルが下がります。その分、削除版へタッチできる人間を増やすことへとつながるでしょう。

まぁ削除権限自体が巻き戻しと違ってホイホイと与えるべき代物じゃないので問題ないと言えば問題ないですが、オーバーサイトを導入し、この手の案件をオーバーサイト係が対処するというのも一案だろうと考えています。削除者のハードルを下げることもできると思います。

あと、明らかにB-2案件となる編集を管理者が見つけた場合は依頼を経ずに緊急削除の対処を行い、確認の目的から管理者MLへ報告を行っていますが、削除者の場合どうするべきでしょうか。--Marine-Blue [ 会話 履歴 電信 ] 2011年3月1日 (火) 14:17 (UTC)

コメント 理想としてはOversightを導入できれば良いのでしょうが、その導入をこのグループの設定の前提にしてしまうと、話が大きくなって議論に時間がかかるようになると思います。もちろんそれでもいいんですが、(緊急も含めて)WP:DEL#B-2に相当するようなものは対処範囲から除いて、削除など実行しない&削除版も見ないように、という方向でも特に大きな問題にはならないんじゃないでしょうか(「削除版をみないよう」に、はいうだけで見たかどうか確認できませんが・・・)。私自身はB-2案件にそれほど関わっていないので、B-2の負荷軽減への期待度がどれほどのものなのかちょっと把握できていませんが、難しい問題が多いB-2分野は、従来通り管理者のみが対処するということでいいように思いました。--青子守歌会話/履歴 2011年3月2日 (水) 12:15 (UTC)
コメント 現状の「管理者がB-2案件を見かけたらその場で版指定削除」というのは雪玉なので、削除者がそれをするのも微妙なところがあります。見つけたら一般利用者として緊急案件を立ててもらう、というほうが現実的でしょう。ただ、ひとつ思うのは、{{確認待ち}}の案件が溜まりがちなので、「確認はしてもらう」というのも案としてないとは言えません。--Jkr2255 (Talk/History) 2011年3月2日 (水) 13:40 (UTC)
コメントとは のような仕組みの中では、深刻な権利侵害が生じることは稀ですから、悪用するのでなければ(これは管理者とも共通する)、閲覧できることで問題は生じないと思います。--Ks aka 98 2011年3月2日 (水) 18:35 (UTC)
コメント悪用のおそれがある場合に何らかの形で解任(管理者の解任等に準ずる形で)できるのであれば、閲覧することによる権利侵害のリスクは低いと考えます。青子守歌さんの主張されている「難しい問題が多いB-2分野は、従来通り管理者のみが対処する」ではなく「不適切な対処を行った場合の後処理が難しい緊急削除案件に関しては従来通り管理者のみが対処する」とし、削除者は緊急性のない通常のB-2案件(提出後1週間を越えたもの)については対処できる方が適切だと考えます。現状では対象となる削除者はいない状態ですが、青子守歌さんの「難しい問題が多いB-2分野は、従来通り管理者のみが対処する」という主張は権限範囲の狭い削除者として従事する利用者は管理者に比べて能力的に劣る者という認識を持たれているように読めてしまいます。--Himetv 2011年4月5日 (火) 11:15 (UTC)

Bugzilla依頼案[編集]

以下は、mw:Manual:User rightsをもとに作成した具体的なBugzilla依頼内容案です。もっと良い案や修正案などありましたらお願いします。--miya 2011年10月10日 (月) 10:57 (UTC)

"Eliminator"
delete
nuke
undelete 
deletedhistory
deletedtext
browsearchive
deleterevision
suppressredirect
ipblock-exempt
unwatchedpages
noratelimit 
  • 井戸端で「構文が違う」と指摘があったので、Marin-Buleさんのメモをもとに、依頼案を簡素化しました。--miya 2011年10月17日 (月) 04:09 (UTC)
  • unwatchedpages を追加し、autopatrol を除去しました。--miya 2011年11月11日 (金) 23:34 (UTC)

markbotedits

以下の機能はいりませんか?--miya 2011年10月10日 (月) 10:57 (UTC)修正--miya 2011年10月13日 (木) 07:59 (UTC)

$wgGroupPermissions['interface editor']['markbotedits'] = true;

利用者:Marine-Blue/メモ/newgroup 2011-09-03T13:13:05の版‎を転記マージしました。--miya 2011年10月13日 (木) 07:59 (UTC)

賛成 依頼案について大筋で賛成します。markboteditsについてですが、これってrollback権限がないと意味をなさないのではないでしょうか。--W.CC 2011年10月15日 (土) 14:27 (UTC)
ご賛成ならびにご指摘ありがとうございます。markboteditsについてはご指摘の通りですね(ほかの権限と混同していました)。--miya 2011年10月15日 (土) 16:37 (UTC)
unwatchedpages

'unwatchedpages'について巻き戻し者のノートで話していたのですが、削除者にも「特別:ウォッチされていないページ」を見られる機能を付与してはどうでしょうか?--miya 2011年10月17日 (月) 04:09 (UTC)

unwatchedpages
依頼案に追加しました。--miya 2011年11月3日 (木) 02:07 (UTC)
autopatrol

依頼案を作るときに他の新利用者と混同して、投票でもここでも出ていなかった'autopatrol'(★)を追加していました。すみません。事後提案になりますが、これを含めておいていいでしょうか。--miya 2011年11月3日 (木) 02:07 (UTC)

autopatrol
Wikipedia:井戸端/subj/新しい利用者グループの作成についてで付与しない方がいいという意見しかありあせんでしたので、取り下げます。--miya 2011年11月11日 (金) 23:29 (UTC)

【報告】Wikipedia:井戸端/subj/新しい利用者グループの作成について#Bugzilla依頼についてにある通り、https://bugzilla.wikimedia.org/show_bug.cgi?id=32370 で導入されました。--miya 2011年11月16日 (水) 01:55 (UTC)

権限付与ルール[編集]


信任プロセス[編集]

Wikipedia‐ノート:管理者への立候補#新しい投票様式を管理者への立候補以外で試用する案(質疑・投票スケジュールについて大幅な変更が加えられる場合)で。Himetvさんが 2011年3月9日 (水) 03:23 (UTC)に提案なさったように、提案中の管理者への立候補簡略プロセスをこの利用者グループに適用することを提案します。具体的には、以下の通り。Wikipedia‐ノート:管理者への立候補で出た案を削除者向けに改変しました。--miya 2011年3月24日 (木) 15:31 (UTC)

  • 投票期間は1週間
    • 立候補から投票開始まで2日間(48時間)、立候補の「予告期間」を置く。遅くとも投票開始24時間前までに、所定のページで予告を完了することが推奨される。
    • 推薦の場合は、被推薦者が立候補サブページで推薦を時刻付き署名で正式に受諾した時点を「予告期間」開始とする。
    • 投票サブページで、投票とコメント投下を同時進行で行う。(投票期間開始前および終了後のコメントはノートに書く)。
    • 候補者に質問があれば、立候補サブページのノートを使う。立候補者は必要に応じて質問に答えることができる。第三者もコメントできる。
    • 賛否票の変更や撤回は投票終了まで可能。

必要得票数[編集]

必要得票数は、以下のとおりでいかがでしょう。率については、50、60、75%など、いろいろ考えられますが、とりあえずたたき台として「60%」を推します。--miya 2011年3月24日 (木) 15:31 (UTC)

  • 管理者の信任ライン以下に引き下げる理由が不明瞭です。著作権やプライバシーの理解についての信頼が管理者以下では困ります。--Noche de la pena 2011年8月19日 (金) 16:07 (UTC)
    • こちらでまず信任率の引き下げを行って、うまくいけば、管理者の信任ラインもこちらにそろえて引き下げることができるのではないかと思いますが、固執はしません。下げるなら管理者信任ラインと同時に下げるほうがいいでしょうか。とりあえず、現在の基準(75%)にそろえる案も下に追加しました。--miya 2011年8月20日 (土) 00:01 (UTC)


管理者投票より緩やかにする案

  • 賛成票が10票以上、なおかつ60%以上

管理者投票と同じにする案

  • 賛成票が10票以上、なおかつ75%以上

特にほかの方から意見が出なかったので、私の案を撤回し、管理者の信任ライン(75%以上)に合わせます。--miya 2011年9月5日 (月) 03:09 (UTC)

有権者[編集]

立候補・投票の資格についてはどうしましょうか。とりあえず、現状のWikipedia:管理者への立候補と同じ、あるいはそれ以下、というのは間違いないところでしょう。

  • 投票の有権者は管理者への立候補と同じにする(アカウント作成後1ヶ月以上、標準名前空間の編集50回以上、直近1ヶ月の記事編集5回以上)
  • 立候補資格はログインユーザー以上に制限しない

投票基準をこれ以上引き下げる必要もないでしょうし、立候補資格は明文化しなくてもRfAで問題なく回っていますから、管理者信任のをそのままで特に問題ないような気もします。--Jkr2255 (Talk/History) 2011年3月26日 (土) 03:04 (UTC)

たしかに、RFAで現在うまく回っている投票資格はそのまま流用がよいと思います。(snip)--miya 2011年3月28日 (月) 06:16 (UTC) 立候補資格についてもRFA方式を準用でいいと思います(実際に導入してから考えたほうがよい気がしてきたため、立候補資格についての06:16時点に投稿した意見を取り消し)。--miya 2011年3月28日 (月) 06:28 (UTC)
よいと思います。試験運用みたいな感じで初めて、ぬるすぎたり厳し過ぎたりしたら見直す感じで。権限付与に関しては、後で井戸端へ戻って決めましょう。--Marine-Blue [ 会話 履歴 電信 ] 2011年3月29日 (火) 15:32 (UTC)
とりあえずはWP:RFAでの資格を準用でよいと思います。導入後に問題が生じたときは変更を検討すればよいのではないでしょうか。--長月みどり 2011年3月29日 (火) 19:31 (UTC)

申請場所[編集]

編集フィルター同様、Wikipedia:削除者/申請のようなサブページで申請することにして、それを英語版のen:Wikipedia:Requests for permissionsに相当するページに展開する方法でどうでしょう。Wikipedia:Requests for permissionsの訳としては「権限申請」「許可申請」「許可依頼」などが考えられますが、今後「巻き戻し者」や「承認された利用者」のような、「権限」というほど重くないフラグも扱う可能性があるなら、「Wikipedia:許可申請」くらいでいいかもしれません。--miya 2011年6月6日 (月) 04:23 (UTC)

(予告)とりあえずWikipedia:削除者/権限申請(仮)を試作して、これとフィルター編集権申請を展開するWikipedia:権限申請を作ってみようと思います。--miya 2011年6月7日 (火) 02:26 (UTC)
(報告と改名予告)Wikipedia:削除者/権限申請を作ってみました。ただ、実際に作ってみるとWikipedia:権限申請のサブページ(Wikipedia:権限申請/削除者)にした方がナビゲーションが容易(各申請ページとWikipedia:権限申請とで行き来しやすい)と考えられたため、en:Wikipedia:Requests for permissionsを参考に[[Wikipedia‐ノート:巻き戻し者#申請場所|]]、[[Wikipedia‐ノート:インターフェース編集者#申請場所|]]と足並みをそろえてWikipedia:権限申請のサブページにしてはどうかと考え中です。--miya 2011年9月14日 (水) 04:27 (UTC)
(報告)依頼場所をWikipedia:権限申請のサブページ、Wikipedia:権限申請/巻き戻し者Wikipedia:権限申請/削除者Wikipedia:権限申請/インターフェース編集者に設けました。--miya 2011年11月16日 (水) 02:23 (UTC)

除去申請条件[編集]

フィルター編集者は「一定期間」活動がなければ他者が除去申請できることが提案されています。削除者の場合、

  • 一年間、編集も権限行使もない(この場合、会話ページに通知)。
  • 会話ページでの通知後も、編集も権限行使もないまま1カ月以上経過。

でどうでしょう。極論すれば、年末年始だけ活動できる、というのでも十分ありがたいと思うのです。--miya 2011年6月7日 (火) 03:01 (UTC)

権限行使しないなら除去すべき、という考え方もありますので、その場合の案も提案しておきます。--miya 2011年7月29日 (金) 17:21 (UTC)

  • 一年間、権限行使がない。
    (権限行使がないまま11カ月以上たった場合、会話ページに通知)。
  • 会話ページでの通知後も権限行使がないまま1カ月以上経過した場合、権限申請ページに報告→除去。
    ただし、削除依頼での確認作業も「権限行使」にあたるため、これを見落としていないか、要確認。

微修正しました。--miya 2011年7月29日 (金) 17:30 (UTC)

予告期間[編集]

Wikipedia‐ノート:管理者への立候補#投票開始に猶予期間(質疑期間廃止の場合)(2011年3月8日~)の議論により、予告期間をとりあえず「48時間」にしています。--miya 2011年9月5日 (月) 03:09 (UTC)

Wikipedia:権限申請/巻き戻し者/Akaniji/20120121の「推薦受諾署名から2日間(48時間)を予告期間とします。」という文が気になって参りました。テンプレートの都合上、推薦も立候補と同じく、推薦から48時間にすべきではないかな、と思いました。推薦者はページを作るときにはすでに候補者と連絡がとれているという前提ですので、推薦受諾署名は予告期間の半分の24時間までにするということにして、24時間以内にその署名がなされなかったらその時点で推薦受諾なしとみなし審議終了でいいと思います。--Ohgi 2012年1月21日 (土) 07:53 (UTC)
たしかに予告期間の説明を「推薦受諾署名から」→「推薦から」としたほうがはっきりしていいですね。ただ、「24時間以内」というのは忙しい人には結構きつそうなので、「予告期間内」(つまり48時間以内)でいいのではないでしょうか。--miya 2012年1月22日 (日) 03:48 (UTC)
予告期間内で良いと思います。--Marine-Bluetalkcontribsmail 2012年1月22日 (日) 05:24 (UTC)
24時間にはこだわりませんので、48時間でもいいとおもいます。--Ohgi 2012年1月22日 (日) 05:51 (UTC)

正式化について[編集]

Wikipedia:削除者信任プロセスについて、その後新しい意見も出ませんので、できれば正式化させていただきたいと思います。--miya 2011年12月25日 (日) 11:30 (UTC)

  • 賛成 正式化でいいと思います。ただ正式化後に現状sysop-mlで行われている緊急特定版削除などの報告は削除者及び管理者で共有すべき内容であると思いますので新しいMLを作成し緊急特定版削除等の内容はそちらに投稿した方がいいのではないでしょうか?--Vigorous actionTalk/History) 2011年12月29日 (木) 14:44 (UTC)
    • ご指摘ありがとうございます。正式化とは節を改めてコメントさせていただきます。--miya 2011年12月30日 (金) 22:57 (UTC)
  • 賛成 正式化に賛成します。--W.CC 2012年1月4日 (水) 11:03 (UTC)
    • ご賛成ありがとうございました。こちらで提案し、お知らせでも「削除者、巻き戻し者、インターフェース編集者、およびこれらの立候補と推薦を受け付けるWikipedia:権限申請について、できれば年明けにも正式化させたい」と告知してから2週間以上たち、異論も出ていませんので、正式化に踏み切りたいと思います。--miya 2012年1月14日 (土) 23:31 (UTC)
  • 賛成 遅くなりましたが賛成いたします。--Marine-Bluetalkcontribsmail 2012年1月17日 (火) 16:13 (UTC)
    • ご賛成ありがとうございました。--miya 2012年1月20日 (金) 06:21 (UTC)

タグをdraftからpolicyに貼りかえました。ただ、立候補プロセスはまだ整備不十分ですので、運営しながらの手直しが必要になると思います。ご協力よろしくお願いします。--miya 2012年1月20日 (金) 06:21 (UTC)

ML[編集]

Vigorous actionさんから以下のご指摘がありました。

正式化後に現状sysop-mlで行われている緊急特定版削除などの報告は削除者及び管理者で共有すべき内容であると思いますので新しいMLを作成し緊急特定版削除等の内容はそちらに投稿した方がいいのではないでしょうか?

MLについては考えないといけないですね。 私はなんとなく、管理者MLのプライバシー・オプション「送信者フィルタ」に削除者のアドレス、もしくは削除者用ML(たとえばWikiJA-eliminators-l)アドレスを登録することでそのアドレスからの投稿を「自動的に 承認する」仕様にすることを考えていましたが、共通MLを作ることは思いつきませんでした。作るとしたらML名はWikiJA-del-lあたりでしょうか。--miya 2011年12月30日 (金) 22:57 (UTC)

今年も宜しくお願いします。Vigorous actionさんのご意見に賛成です。別途MLを作成した方が権限の異なる案件対応には宜しいかと思います(管理者MLの話題が大幅に減る気もしますが)。--ろう(Law soma) D C 2012年1月3日 (火) 23:39 (UTC)
共通MLの作成に賛成します。管理者と新権限の方々との間での情報共有の仕組みは必要不可欠ですし。-W.CC 2012年1月4日 (水) 11:03 (UTC)
賛成します。ただ、管理者権限持ちには管理者MLと共通ML両方のモデレータを掛け持ちする人を何人か置いたほうが良いでしょうね。新規参加の管理者はふたつのMLに同時加入しますので、同時にやるなら一人で処理できたほうが良いんじゃないかと。--Marine-Bluetalkcontribsmail 2012年1月17日 (火) 16:13 (UTC)
モデレータ掛け持ち含めて作成に賛成します。ML作成依頼はやったこと無いので、わかる方いらっしゃいましたらお願いします。--miya 2012年1月23日 (月) 06:05 (UTC)
モデレータ掛け持ち含めて賛成します。ML作成依頼は前にやったことがありますので、お手伝いできるかもしれません。--Vigorous actionTalk/History) 2012年1月23日 (月) 06:15 (UTC)
ありがとうございます。他の方からの異論・対案も出ていませんので、よろしくお願いします。--miya 2012年1月31日 (火) 16:48 (UTC)

関連ページ[編集]