Wikipedia:井戸端/subj/新しい利用者グループの作成

現在ご覧になっているのはWikipedia:井戸端のサブページです。
この話題の最新の投稿から10日間経過するか、最初の投稿から30日が経過すると、井戸端への読み込みが解除されます。
井戸端への読み込みが解除されても、Category:井戸端の話題から参照できます。

新しい利用者グループの作成

最近、特定機能の利用を目的に立候補される方が出てきました。ウィキペディア日本語版では利用の制限された機能の多くが管理者グループのみに与えられており、これらを利用するためには管理者へ立候補する以外に選択肢がありません。しかし特定機能の利用を目的にするのは管理者グループに所属しながら特定機能の使用しか行わないと言うことであり、この手法は好ましくないと見る方も少なからずおられるのではないかとます。

そこで今後のさらなる立候補も想定し、他言語版などを参考に、管理者の持つ機能を少し小分けしたグループを作ってみてはいかがでしょうか。管理者グループに所属しながら与えられた機能を持て余すのが好ましくないのであれば、最初から機能を絞り込んだグループへ所属させてみてはどうかと言う提案です。以下にいくつかグループの案を挙げてみます。

巻き戻し者 (rollbacker)

荒らしなどの巻き戻しのみを行うグループです。英語版やイタリア語版、スペイン語版など複数の言語版で運用実績があるほか、ウィキメディア全体で[[Special:GlobalGroupPermissions/Global_rollback|MediaWiki:Group-Global rollback]]としても運用されています。

この利用者グループに与えられることが想定される機能は以下の通りです。なお、これはあくまでも案として多めに挙げています。細かい部分は具体案として詰める段階で追加・削除べきものと考えます。

編集をワンクリックで巻き戻す (rollback)
巻き戻しを行う際に編集をボット扱いする（荒らしの編集をRCやウォッチリストから隠すために使用する） (markbotedits)
移動を行う際、移動もとにリダイレクトを作成しない (suppressredirect)
編集を自動的に巡回済みとして扱う (autopatrol)

削除者 (eliminator)

削除関係の操作のみを専門で行うグループです。これと同様の機能を持つグローバルグループはないようですが、ポルトガル語版やヒンディー語版で運用されています。

想定される機能は以下の通り。あくまでも多めに盛り込んだ案であり、このまま運用されるとは限りません。

ページの削除 (delete)
ページをまとめて削除 (nuke)
削除されたページを復帰 (undelete)
削除されたページの履歴を閲覧 (deletedhistory, deletedtext)
削除されたページのタイトルを検索する (browsearchive)
版指定削除と版指定削除されたものの復帰 (deleterevision)

システムメッセージ編集者 (interface edit)

システム関係のメンテナンスを目的とし、一般利用者が編集できないページのみを編集する権限です。あまり参考になる運用事例がないようですが、ヒンディー語版で導入例があるほか、全言語版で[[Special:GlobalGroupPermissions/editinterface|MediaWiki:Group-editinterface]]としても導入されているため、決して無茶な機能提案ではないと思います。

想定される機能は以下の通りです。案であるため、ここから追加・削除が想定されます。

システムメッセージの編集 (editinterface)
全保護されたページの編集、保護レベルは変更できない (editprotected)
他利用者のカスタムJS/CSSの編集 (edituserjs, editusercss)
ページの削除（復帰は出来ない） (delete)

管理者よりも権限付与を容易にする（削除依頼や保護依頼のような感じ？）代わりに、その代わり問題があれば管理者或いはビューロクラットが即時で剥奪を行えるような形で運用できないかと考えております。イメージとしては編集フィルター編集者が近いでしょうか。あとIPブロック適用除外も参考になるかな？

新しいグループを作ることやグループの追加案などについてのご意見を頂けると幸いです。なお、機能割り当てはあくまでも大雑把な案です。どのグループがどの機能を使えるようにするかはこの場でなく、実際にぞれぞれ導入を考えていく段階になったときに詰めたいと考えております。--Marine-Blue [ 会話履歴電信 ] 2011年2月22日 (火) 11:20 (UTC)[返信]

管理者より権限付与を安易にするというのは賛成できませんね。たとえ機能制限版であっても、削除やシステム文字列変更のような重大で危険な操作を許す以上、管理者と同等の厳しい選考があって然るべきです。簡単に緩めることがあってはなりません。小型化した銃を安売りしたいというのであれば断固反対します。今の管理者から何でも壊せるバズーカを奪って、目的に合わせた小銃に持ち替えさせるというのであれば賛成も出来そうですが、そういう提案ではなさそうです。--QQ81 2011年2月22日 (火) 11:39 (UTC)[返信]

賛成草案とはいえ、非常によく練られていると思います。立候補の所信表明において〇〇の機能しか行使しない、とするのはコミュニティとのある種の契約だと思いますが、現状では一度信任されてしまえばその契約が守られなかったとしてもそれを咎めることはできません。そのため、どのような立候補者に対しても全ての管理機能を行使することの適正を測る必要があり、立候補者・コミュニティ双方の負担が大きくなっています。この案が採用されれば特定の分野に貢献する意欲のある利用者が立候補しやすくなり、プロジェクトにとって大きなプラスになるでしょう。ひとつ

質問ですが、このような管理機能の限定はシステム的には可能なのでしょうか？それとも、例えば目的外の機能が行使されたら解任などそうした運用面での対応になるのでしょうか？--T_suzu 2011年2月22日 (火) 12:28 (UTC)[返信]

英語版などの言語間リンクを見ていただければわかりますが、実例として挙げたところでは実際に機能を限定した利用者グループを作成しています。また、グループの新設作業はBugzillaでシステム管理者に設定をお願いすることになります。--Marine-Blue [ 会話履歴電信 ] 2011年2月22日 (火) 12:49 (UTC)[返信]

賛成 +機能追加提案 rollbackerとeliminatorにnoratelimitが無いと速度制限に引っ掛かる場合もあるように思うため必要ではないでしょうか?、また、上記3つの権限にipblock-exemptがあっても良いように思います。--Vigorous action （Ｔａｌｋ/History） 2011年2月22日 (火) 13:29 (UTC)[返信]

コメント イメージ的には立候補の時に「管理者として」行使する権限をアラカルト方式で選べるようにするというよりは、「管理者の下に置かれる」新たなグループを作成するという提案なのでしょうね。それなら、ブロック権限は管理者のみが持っているということも納得できます。この議論とは直接関係ありませんが、この案が採用されたら、これら新たなグループでの経験を管理者立候補へのprerequisiteにしても良いかもしれませんね。ちょうど管理者経験がCUやビューロクラットへの条件であるように。--T_suzu 2011年2月22日 (火) 13:53 (UTC)[返信]

賛成基本的な方向性として賛成します。詳細については各権限グループ個別に議論した方が良いでしょう（3つ並行して進められますから。あと、各権限グループに割り当てる権限が何かも大事ですが、だれ（どの権限グループ）が利用者に対してその権限グループを追加あるいは除去できるのかもシステム管理者への依頼の時、運用時にも重要になってくると思います。編集フィルター編集者を参考にということは、追加除去は管理者が実行できる、とするのが良い/想定されている感じでしょうか。まぁこちらも「詳細」の部類に入ることなので、個別に議論しても良いと思います。個人的な感触を言えば、rollbackerとinterface editorはそれほど大きな権限でもないのでスムーズに導入できそうですが、eliminatorは慎重に議論していかないといけないのかなと思います。--青子守歌（会話/履歴） 2011年2月22日 (火) 13:57 (UTC)[返信]

賛成基本的に賛成です。管理者の不足は引き続き懸案として残りますので併行して管理者を増やす取組は継続しなければなりませんが、ご提案のような利用者グループ（co-管理者と言ってもよい）を作成することには、削除依頼等の滞留の改善と利用者の管理業務への参加促進というメリットがあると思います。--ろう(Law soma) ^D _C 2011年2月23日 (水) 01:43 (UTC)[返信]

コメント 大まかな方向性として賛同が得られているようなので、もうちょっと話を深めてみます。概論の段階ではコメントできることも少ないと思いますゆえ。--Marine-Blue [ 会話履歴電信 ] 2011年2月23日 (水) 16:17 (UTC)[返信]

IPブロック適用除外

節分けました。--青子守歌（会話/履歴） 2011年3月2日 (水) 11:55 (UTC)[返信]

コメント 大筋賛成です。一点分からなかった部分の質問です。IPブロック適用除外で自動ブロックが掛からなくなると、アカウントを作成しそちらで何をやってもメインアカウントは無傷のまま使用できる、というまずい状態が生まれてしまう様に思いますが、想定される利益はどのようなものでしょうか？これらフラグは時間がたてば人数もかなり多くなるでしょうから大量のアカウントが多重アカウント使い放題となるとかなりまずいことになってしまうよう思います（現在IPブロック適用除外が自動で付与されているのは管理者のみと思います）。IPでのブロックの競合は継続的に活動されているアカウントに限って言えば、そこまで発生する事象でもないですから（特別:登録利用者一覧/ipblock-exempt、現状三件）、利点がそこまで大きくないなら避けた方が安全じゃないかと思われます。--Was a bee 2011年3月2日 (水) 11:20 (UTC)[返信]

多分大きな誤解をされているように思います。まず、「IPブロック適用除外者」(ipblock-exempt)は、申請があってある程度信頼できそうだと判断されたら特に合意も必要なく付与できるよう運用されていることを見ても分かる通り、一定の活動実績と信頼度がある利用者に対して「IPブロック、自動ブロック、広域ブロックを回避」(ipblock-exempt)を付与することは問題視されるようなことではありません。もし仮に、新しく作成する権限グループの利用者が悪意をもって荒らしに来る（つまり、ipblock-exemptが問題になる）ような場合は、その利用者アカウントをブロックして権限を剥奪してしまえば済む話で、決して「多重アカウント使い放題」（防ぐ術がない）というわけではありません。これは「管理者」(sysop)でも、どのグループのどの権限にしても同様であって、「問題を起こさないだろう」ということは前提の上で付与されるものですから、「まずいことになってしまう」ということは起こりえないと考えられます（悪意に対する脆さで言えば、「編集フィルター編集者」(abusefilter)の方がよっぽどだと思います）。なお、せっかくなので、ipblock-exemptを付与しておく利点についても一応述べておきますと、まずは全体を通して言えば、もしその利用者がIPブロックに巻き込まれた時にいちいちipblock-exemptの申請をしてそれをsysopが確認して付与して・・・という手間が省ける（先に述べたように、もともと信頼できる利用者なのですから、判断をする必要性がほぼない）という点があります。さらに個別に（各グループの運用にもよりますが）考えれば、巻き戻し者および削除者は対荒らしでの活動も期待されている（特に前者は）グループですから大規模荒らしによって広域ブロックが掛かった場合での荒らし対策について、またインターフェース編集者は同様な事態で告知系のシステムメッセージあるいはスクリプトの編集およびその他の対応について、それぞれIPブロックに巻き込まれることなく迅速に実行できるという利点があります。以上より、「IPブロック、自動ブロック、広域ブロックを回避」(ipblock-exempt)があることの利点は、あることの欠点（＝ほぼゼロ）を上回るため、この権限を割り当てておくことは必要なことです。--青子守歌（会話/履歴） 2011年3月2日 (水) 11:55 (UTC)[返信]

コメント 私もWas a beeさんと同じような心配はしています。~~グローバル利用者グループでもその権限は付与していないようですし~~、現状から考えてあまり使われないと思われるなら付与しない方がいいかなという気はします。管理者の方の立場としてはipblock-exemptの申請受理の手間をかけたくないのは理解できますので、積極的に反対するわけではありませんが。--Kurz 2011年3月2日 (水) 12:20 (UTC)[返信]

グローバルグループについては、もし何らかの特殊な意図を持って、そのローカルウィキがそのIPアドレスからの編集を禁止にしている場合など、ローカルでの運用を上書きしてしまわないようにという意図があり、付与されている権限は必要最低限になっています。なので、ちょっと例として挙げるのは不適切だと思いますので、その点だけ指摘しておきます。ただしコミュニティーのみなさまが「使わないなら与えるな（緊急時のことなんか考えなくていい）」という方向であるなら、それはそれで良いと思います。--青子守歌（会話/履歴） 2011年3月2日 (水) 12:46 (UTC)[返信]

コメント 緊急事態について考えなくてもいいってことはないですよ。考えた上で、青子守歌さんは緊急時のメリットの方を大きくみて、私は緊急事態のない通常時のデメリットの方を大きくみたというだけでして。大規模荒らしへの対処の実態に詳しいわけではないので、緊急事態というのを甘く見すぎだったかもしれないですね。--Kurz 2011年3月2日 (水) 13:26 (UTC)[返信]

デメリットについては、Wikipedia:多重アカウントの基となっている英語版の最新版を翻訳・導入して、多重アカウントへの対応を英語版なみに厳重にすることで回避できるのではないかと考えています。--miya 2011年3月2日 (水) 15:35 (UTC)[返信]

コメント ルール運用を厳格化するぐらいなら権限を制限するほうが確実ですし、その方がシステムのサポートがある分だけ監視の手間がかかりませんよ。というか、権限（アクセス制御）って本来そうやって使うためのものでしょう。あと英語版を参考にするのであれば、英語版ではこの権限はipblock-exemptグループとして単体で運用されているようですし、日本語版でもそれに相当する「IPブロック適用除外者」グループが一応あるようですから、単体で運用するようにすればいいんじゃないかなという気はします。--Kurz 2011年3月5日 (土) 01:18 (UTC)[返信]

利用者グループ統計

	登録利用者	2,258,133
	活動中の利用者	12,545
	管理者	40
	ビューロクラット	5
	チェックユーザー	4
	オーバーサイト	4
	削除者	5
	インターフェース管理者	10
	編集フィルター編集者	27
	巻き戻し者	40
	ボット	54
	IPブロック適用除外者	35

コメント 右の表にあるように、活動中のアカウントで見てもIPブロック適用除外は一万分の三程度（0.03%）の確率でしか発生しませんし、同一フラグの利用者全てが一気にかかる可能性はほぼゼロに近いでしょうから、迅速性についてはそれ程心配する必要はないと思われます。仮に万が一で発生しても裁量で即座に付与しているようですから手間も大きいものではないでしょう。数年に一回あるかないか、数分から10分の手間となるでしょうか。

とはいえ多重アカウントでブロックされるアカウント群は、そのどれかについては普通の投稿を行っている事が多いですし、徹頭徹尾おかしなアカウントばかり使っているという例はそう多くないと思います。ですから一つのアカウントが信頼できても、それが多重アカウントをおかしな方法で使用をしないことの保障にはなりません。そうなるとフラグ付与のハードルが上がってしまいます。CUは10人しかおらず、状況が分からなければ対応もできませんし、全てのシチュエーションをチェックする事も難しいです。

最終的にフラグが数百人程度にまで付与されたとき（ボットの数から類推すればそれぐらいになるのかな、と思います）、こうしたフラグをとった人が不正な多重アカウント使用をすることへの抑止力は相当に小さいでしょうから、おかしな多重アカウント使用をしてしまう人も必ずでてくると思います（IPブロック適用除外がなければ、つまり一般利用者と同じ環境であれば、変な多重アカウント使用をしていて突然それがブロックされた場合、メインアカウントで投稿しようとして自動ブロックでバレる危険性があります。またおかしなアカウントがブロックされてから適用除外を受けても、「メインアカウントの最終投稿時刻」と「適用除外が付与された時刻」の間の投稿ブロック記録も公開されますので、あまりにあからさまな多重アカウント利用はすぐ勘付かれるので出来なくなります。最初からIPブロック適用除外が付いていると、どちらのリスクもなくなりCUにブロックされるかどうか、だけが危険性となり、微妙なまたは複雑な案件についてはサブアカウントがブロックされてもそれがメインアカウントに及ぶ危険性はほぼ皆無となると言っても良いでしょう）。

そうなれば管理者立候補などと同じようにフラグの付与基準が上がってしまう問題が出てきます（つまり多重アカウントを変な方法で使用しないという確信がない限り、申請が出てもとりあえず反対してみる、といったような流れが出てきてしまように思います）。管理者と同じくらい長期間、詳細に投稿記録を見てからでないとフラグが付与できないのは本提案の趣旨から言って違うでしょうし、本人にとっても無駄にハードルが高くなってしまうと思います。--Was a bee 2011年3月2日 (水) 14:29 (UTC)[返信]

まず最初に、1つだけ確認の意味を込めて書いておきますが、「IPブロック、自動ブロック、広域ブロックを回避」(ipblock-exempt)が割り当てられているグループに所属している利用者であっても、その利用者の多重アカウントすべてがIPブロック適用除外となるわけではありません。あくまでグループに所属しているアカウントのみが適用除外です。言い換えれば、その利用者の利用しているIPアドレスからの投稿がブロックされている状態であれば、その本アカウントにipblock-exemptが割り当てられていようがなかろうが、「おかしな方法」で使用しているようなものも含めて、同じIPからの他のすべての多重アカウントからの投稿はブロックされます。ですから、懸念されるような「ブロック中のIPから多重アカウントをあやつって編集する」という事態は起きえません。操作できるのはグループに所属しているアカウントのみであり、その利用者自身に問題があるのであれば、その本アカウント自体もブロックあるいは権限剥奪してしまえば何もできなくなります。つまり、多重アカウントの使用にはipblock-exemptは関与しません。ただし一方で、この話は、1人の利用者がipblock-exempt権限のあるアカウントを複数所持していて、それらを不正に使用するような場合は例外です。なので、もしそのような事態さえも危惧されているというのであれば、それはリスク評価基準の価値観の違いでしょうから、それを危惧している人が多数派なら私はそちらに合わせます。--青子守歌（会話/履歴） 2011年3月2日 (水) 15:22 (UTC)[返信]

サブアカウントで不埒なことをしても本アカウントがIPブロック適用除外だと影響がないことになりますが、IPブロック適用除外はIPに対するブロックを解除したりブロック発動を抑制するのではなく、アカウントがブロックに関係なく投稿できるだけです。IPへのブロック設定は変更されません。ブロック中のIPからIPブロック適用除外とそうでないアカウントが投稿を試みた場合、適用除外の人は自由に投稿できて、除外されない人は引き続き投稿を規制されます。

	IPブロック適用除外	ログイン利用者	匿名利用者
ブロックなし	投稿できる	投稿できる	投稿できる
匿名のみブロック	投稿できる	投稿できる	投稿できない
ログイン利用者もブロック（自動ブロックもこれ）	投稿できる	投稿できない	投稿できない

また、IPブロック適用除外のアカウントをブロックした場合も、自動ブロックは発動します。反対意見も大事だし、考慮したいのですが、事実誤認っぽいのでちょっと反対理由になってないです。--Marine-Blue [ 会話履歴電信 ] 2011年3月3日 (木) 10:11 (UTC)[返信]

事実誤認ではないです。この規定が入っていても不正な投稿をしようとする人にしか利益がありませんよね。英語版にもそうした不要なフラグはないです。積極的に必要な理由があるのであれば賛成しますが、とりあえず入れとくか、というものであればこれはコミュニティにとって不利益しかないです。

除外は今まで6年間で登録アカウントが50万、継続活動アカウントが平均して約10000、この状態でIPブロック適用除外は6年間で3件だけです[1]。フラグ付与が数百件程度であればIPブロック適用除外を入れる利益はほぼゼロです（つまりこの規定を入れても良い方向に効果を発揮する場面は無いでしょう）。これに対し投稿ブロックの件数、CUが提出されている件数、またコメント依頼などの議論場面に知識が十分にありながら投稿記録のほとんどないようなおかしなアカウントが現れる回数は、ご存知の通り膨大な数に上ります（つまり確認してチェックを行わなければならない範囲は増大し、CUしなければならない回数も増大し、CU依頼を提出する作業も増加します）。そしてフラグの付与もしにくくなります（自分は英語版で議論にほとんど参加したことがないですが、申請から数時間でロールバック権限を付与されました。IPブロック適用除外のような見えない所で不正を行えるようなフラグであればこうはいかなかったでしょう）。規定を入れるべき積極的な理由があるのであれば賛成しますが、とりあえず入れとくか、というものであればCUの責任範囲を初めとしてコミュニティ全員の負荷が増大するだけの規定でしょう。労力が増えるだけで誰も得する所がないですよ。--Was a bee 2011年3月3日 (木) 22:46 (UTC)[返信]

IPブロック適用除外でIPブロックが解除されるかのようなニュアンスだったので、そういう前提では考慮のしようがなかったと言うことです。IPに対するブロックが適用除外の外で引き続き有効となることを踏まえた上で反対するのであればそれは考慮されるべき意見と考えます。--Marine-Blue [ 会話履歴電信 ] 2011年3月4日 (金) 16:55 (UTC)[返信]

コメント まずWas a beeさんのおっしゃってるIPブロック適用除外は6年間で3件しかない件ですが、私の知りえるところでは申請はもう少しあります。ただ申請者がブロック逃れの対象者又は、編集件数が極端に少なく付与するに至らなかったなどで認められなかったなどの理由があると聞いています。またIPブロックで対象が匿名のみになっていないブロックの件数もオープンプロクシー以外ではそれほど多くなく、IPブロック適用除外自体もあまり知られていない事も考えられます。公開プロキシー以外では出来るだけ短期間に設定するようにしています。この様な事情から申請する手間等を考えて付与申請が少ない、よって付与された人が少ない事も考えられます（実際私も管理者になる2ヶ月ほど前に広域ブロックに巻き込まれた事がありますが、短期間であった事から申請しなかったという事があります)。ただ、自動ブロック解除を逃れる目的でipblock-exemptのついているアカウントを使用するようなある意味程度の低いブロック逃れをしたり、匿名のみではない広域ブロックでIPブロック適用除外を悪用していたとすると、かなり早いうちに関わったすべてのアカウントのブロックがなされるでしょう。--Vigorous action （Ｔａｌｋ/History） 2011年3月4日 (金) 22:27 (UTC)[返信]

これは単純なブロック逃れの話というよりも「ブロックされても構わないような、ほぼノーリスクで嫌がらせ投稿を行える地盤が用意される」というものです。ご存知のとおりCUは自分で十分に状況を把握した時しか対応ができませんし（疑いがかなりの程度の確信に至るまで、疑わしいという事の公表もしないでしょう）、そしてそもそもCUには調査の義務がなく自発的に「調べよう」と思った場合しか調べません。加えて調べて見てもその分野の事が分からなければ何が行われているかは分かりません。ですから「かなり早いうちに関わったすべてのアカウントのブロックがなされるでしょう」というのは、現在の状況から見ても、残念ながら実際には無理でしょう。仮に「アカウントに対して行われた全てのブロックに対してCUを行い、その結果を書く」という事をルール化するなら言われたことは可能ですが、しかしそれはあまりの労力になってしまいます（もちろんそれが出来るなら、透明性の上でも安全性の上でも一番理想的ではありますが）。--Was a bee 2011年3月6日 (日) 12:47 (UTC)[返信]

コメント えっと･･･　Was a beeさんがおっしゃっているのは、ある種のブロック逃れのケースなんだと思います。

アカウントAとBを持っている人がいて、ウィキペディア日本語版の投稿ブロックは人に対するものなので、アカウントAが投稿ブロックされたら、Bでの投稿も禁止されます(user name block は別論)。そして、自動ブロックがあればアカウントAが投稿ブロックされた場合に、すぐにアカウントBに切り替えても、たいていは自動ブロックされることになります。ですから、自動ブロックが機能しなくなるipblock-exempt権限を有するということは、ある種の投稿ブロック逃れに利用できるということですし、またその準備としてipblock-exempt権限を得るということも考えられることでしょう。

もっとも、自動ブロックを回避するためには可変IPで接続しなおせすむことなので、もともと自動ブロックによるブロック逃れ抑止力は大したものではない、とも思います。とはいえ、たしかに一つの抜け道ではあるでしょう。また、故意ではなく、アカウントAがブロックされたことに気づかずにそのままBで投稿を続けたという場合も考えられます。

他方で、「不正な投稿をしようとする人にしか利益が」ない、というのも言いすぎでしょう。前述のような投稿ブロック逃れとなる場合ではない、つまり本人には何の非もないのに広域IPブロックに巻き込まれてしまったという場合には、それを回避できることは本人にとって利益ですし、ウィキペディア日本語版にとっても利益です。

さて、私としては、巻き戻し者 (rollbacker)にipblock-exempt権限は不要だろうと思います。巻き戻し者が何人かIPブロックに巻き込まれたところで、それほど困った事態になるようには思えません。

削除者 (eliminator)については、ipblock-exempt権限を付与するべきでしょう。特定版削除の記事移動→削除→特定版復帰(複数回)→移動→報告と事後処理という一連の作業の途中でIPブロックに巻き込まれるとかなり困ったことになります。また、特定版削除ではなくとも、ひとかたまりとして処理し報告するべき削除作業の途中で中断されてしまうと、やはり問題でしょう。逆に、ipblock-exempt権限を付与するべきではないというほど人格的に信頼できない人は削除者にするべきではないと思います。

ただ、削除者にipblock-exempt権限を付与する場合、その制度的意味合いについては整理しておく必要があると思います。管理者の場合、自分も投稿ブロックを行い、また解除する権限の信任をコミュニティから受けているわけですから、自分への投稿ブロックを解除して投稿を継続することも、いちおう権限の範囲かもしれません。投稿ブロックをかけた管理者の判断が、かけられた管理者の判断に優越するという理由がありませんから。ですから、管理者がipblock-exempt権限を持っているということは、投稿ブロックは管理者アカウントには強制されない、という信任制度の帰結だと考える余地もあります。しかし、削除者の場合はそうではなく、あくまで広域IPブロックなどへの巻き込まれを防ぐためなのであって、投稿ブロックの正当性を裁量的に判断する信任がその人にあるわけではないのですから、自分が持っている多重アカウントのどれかに投稿ブロックがなされたら、削除者アカウントであっても投稿してはならない、というべきでしょう(user name block は別論)。--mizusumashi（みずすまし） 2011年3月4日 (金) 09:16 (UTC)[返信]

管理者になってから暴走して解任される人もいれば、この人が多重アカウントを使ってたなんて・・と驚くこともあり、アカウントの信頼性は残念ながらなかなか判断ができないです。今回の話のような、強い意味での信頼性（見えない所で何を行うかまでを含めての信頼性）を加味するとなると、管理者やビューロクラットの信任手続きと同じく、やはり面倒な質疑応答とコミュニティの投票という形式を経る必要があると思います。ある管理者の裁量だけでそこを決めてしまうと、周囲も「なぜこんなのにフラグを与えた」という話も出てくるだろうと思います。一連の処理が一気に出来た方が良いのは、それは普通の投稿者が行う白紙化後の再投稿や、節の除去後の別記事への投稿など、多くの場面で共通だろうと思いますが、これは確率として万に一つ、数十万から数百万アカウントに一回といった可能性と思いますが、そうした非常に稀なときにIPブロック適用除外があれば便利とは言え、なければ破滅的というものではないでしょう（気づいた管理者や同じフラグを持ってるほかの利用者が戻す、または作業の続きを担う、という事ができます）。ブロックについては「逃れ」という意味と、そして「突如としてブロックに巻き込まれ、そこから自分の変なアカウント使用が露呈するリスク」を消さずに置いておく事です。CUも10人しかいましやはり状況を把握し続けるのは難しいのが現状でしょう。上でも書いたように仮に「アカウントに対して行われた全てのブロックに対してCUを行い、その結果を書く」という事をルール化するなら言われたことは可能ですが、しかしそれはやはりあまりの労力になってしまうでしょう。--Was a bee 2011年3月6日 (日) 13:03 (UTC)[返信]

最終更新から2週間ほどたち、議論が一定程度出尽くしたと思いますので、各論のページに場を移しました。ともなう負荷とリスクの上でそれでもあえて付与を行うという形では特段なかったのではないかと思います。こうした点についてリスクを排除して副作用を抑えつつ、その上でこの機能の導入が進んで拡がり管理者が楽になるよう普及していけばと願います。--Was a bee 2011年3月19日 (土) 21:28 (UTC)[返信]

詳細の検討

機能の割り当てについてある程度方向性を決めた後、投票で最終的に導入を決定することになると思います。また、ある程度機能割り当てが決まったら、並行してそれぞれ運用方法を決めていければと考えています（何が出来るのか決まらない段階では議論しづらい部分があると思います）。権限付与・除去に関しては、管理者・ビューロクラットどちらでも良いという認識です。双方のメリットを考えた上で決めていきたいと思います。

Vigorous actionさんが挙げられた速度制限とIPブロック適用除外を加えた上でそれぞれ案1として改めて掲示します。--Marine-Blue [ 会話履歴電信 ] 2011年2月23日 (水) 16:17 (UTC)[返信]

質問この後の議論の流れ（予定）は、

まず各グループの割り当て権限を決める（各グループの目的をはっきりさせることと同義？）
その後、どういった形で権限の付与および除去を行なうか、具体的に付与/除去申請の方法および条件を決める
最後に、その権限付与除去条件を考慮して、グループ権限の付与除去権限をどのグループ（ビューロか管理者かもしくは自分自身か）に割り当てるか決める

という方向を想定しているということでいいでしょうか？規模はある程度大きくなりそうな議論なので、あらかじめ流れをきちんと把握して決めておいたほうが良いかと思います。--青子守歌（会話/履歴） 2011年2月23日 (水) 17:57 (UTC)[返信]

コメント 1と2の流れはご推察のとおりです。1（出来ること）がほぼ決まったら2（使い方/運用方法）へ移行、2へ進んで以降で何か問題が見つかれば1の決定に微修正が入るかも（殆どないでしょうが）…と考えております。権限付与関連については順番を考えておりませんでしたが、どちらかと言うとルールの話になりますので、順番を考えると3で良いでしょうね。

この話題の性質上、機能割り当ての細かい決定に関しては意見を出す人が多少偏ってしまうはずです。しかし最終的には可能な限り多様な意見を取り入れることが必要ですので、参加者の偏らない話題は後のほうに持ってきたほうが良いと考えます。偏った人の決定した事項について承認を求めるためにも。--Marine-Blue [ 会話履歴電信 ] 2011年2月24日 (木) 07:24 (UTC)[返信]

了解しました。ではとりあえずこのような流れで行くことを前提に意見など出していきたいと思います。ところで、権限の割り当ての話はこの下でやるとして、実際の運用方法まで踏み込むような議論（つまり2以降）の場合は、別途、Wikipedia名前空間に各グループの説明ページを作って（どうせ後から必要になるので）、個別に審議した方がよいと思いますがいかがでしょうか？--青子守歌（会話/履歴） 2011年2月27日 (日) 16:03 (UTC)[返信]

そろそろ分離したほうがよさそうだとは思ってましたが、説明ページと言う手がありましたね。取り敢えずの簡単なものを立ち上げます。--Marine-Blue [ 会話履歴電信 ] 2011年3月1日 (火) 12:28 (UTC)[返信]

報告段々とページサイズも大きくなってきたため、続きは新しいページで。Wikipedia:巻き戻し者、Wikipedia:削除者、Wikipedia:インターフェース編集者とそれぞれのノートをご覧ください。--Marine-Blue [ 会話履歴電信 ] 2011年3月1日 (火) 14:36 (UTC)[返信]

巻き戻し者

名称：巻き戻し者（規定の英語名は rollbacker）
概要：不適切な編集の差し戻しに関する機能を割り当る

機能割り当て案1

編集をワンクリックで巻き戻す (rollback)
巻き戻しを行う際に編集をボット扱いする（荒らしの編集をRCやウォッチリストから隠すために使用する） (markbotedits)
移動を行う際、移動もとにリダイレクトを作成しない (suppressredirect)
編集を自動的に巡回済みとして扱う (autopatrol)
速度制限を受けない (noratelimit)
IPブロック適用除外 (ipblock-exempt)
権限付与/除去：管理者 or ビューロクラット

機能の説明：管理者に割り当てられた巻き戻し機能と移動機能をオプション制限なしで割り当てた状態です。

グローバル権限に準じた形となりますが、他言語版のローカル権限よりも機能割り当てを多めに設定した形で案として出しています。他言語版では巻き戻しのみを許可しているところが多いようです。--Marine-Blue [ 会話履歴電信 ] 2011年2月23日 (水) 16:17 (UTC)[返信]

コメント まずは割り当て権限の議論をということなのでそちらに論点を絞ると、「転送ページを作成せずにページを移動」(suppressredirect)についてのみ少し疑問があります。荒らしなどの不適切な編集が大規模にあったときなどに使われるものなので、たしかに移動荒らしのようなものに対してはsuppressredirectは有用かもしれません。しかし、本当にリダイレクトを作成しなくてよいか判断するというのは、つまりリダイレクトを削除してよいかどうかの判断で、巻き戻し(rollback)という編集対応を行なうグループには適切でない（荷が重すぎる）ように思います。巻き戻し者にsuppressredirectを割り当てたからと言って不適切な利用がされるということはあまり予想してませんが、「編集対応」と「削除」の違い（後者のほうがより強い対応とみなされている）という部分の境目ははっきりしておいた方が、後のことを考えるとよいかと思います。というわけで、絶対反対というわけではないですが、suppressredirectの割り当てのみ消極的反対にしておきます。--青子守歌（会話/履歴） 2011年2月23日 (水) 17:57 (UTC)[返信]

権限の範囲については特に問題ないと思います。suppressredirectについては現状ではsysop以外にbotにも付与されている事から、特に問題ないのではないかと考えます。(乱用が起こるようであれば、権限停止すればいいわけですし…。）--Vigorous action （Ｔａｌｋ/History） 2011年2月25日 (金) 09:32 (UTC)[返信]

コメント 権限の範囲について大筋で賛成します。suppressredirectについてですが、本当にこれが必要な方は、（権限の性質上）削除者になっていただくのが本来の目的にかなっていると思いますので、下でも議論されているようにそちらへの移動を検討してみるべきかと思います。ただ、Vigorous actionさんもご指摘のように、そこまで神経質になる問題ではありませんので、積極的に反対はしません。--W.CC 2011年2月25日 (金) 12:47 (UTC)[返信]

コメント suppressredirectは削除と違ってページの履歴を吹っ飛ばすことにはならないため、提案した側としては入れることそのものに大きな問題はないと考えています。ただ、移動荒らしって結構少ないですし、リダイレクト非作成を取っ払って、なるべく巻き戻しに特化した単純なものにして、削除者よりもフラグを付与しやすくするほうが良いかもしれませんね。--Marine-Blue [ 会話履歴電信 ] 2011年2月25日 (金) 13:44 (UTC)[返信]

コメント 少しでも負荷を減らすという観点から、suppressredirectは必要と考えます。Marine-Blue様のおっしゃる通り、履歴が消えるわけではありませんので、特に問題はないと思います。権限の範囲については、これでよいと思います。--Ac-d c 2011年2月25日 (金) 23:53 (UTC)[返信]

「少しでも負荷を減らすという」観点からすれば、どうしても巻き戻しだけでは不便なことが多いわけで、そういう方はW.CCさんがおっしゃるように下の削除者グループに加わってもらうか、もしくは管理者グループになってもらえれば良いと思います。最初にも述べてますが、これがあることで大きな問題が引き起こされることは今のところ危惧していませんが、単純にシステム的あるいは運用上の面で、suppressredirect権限は切り分けておいて、巻き戻し（編集対応）に純化しておいた方が良いだろうということです（Marine-Blueがおっしゃっているように、フラグの付与のしやすさも変わってくるだろうと思います）。--青子守歌（会話/履歴） 2011年2月27日 (日) 16:03 (UTC)[返信]

報告ページサイズが大きくなったため、Wikipedia:巻き戻し者とそのノートにまとめと続きを書きました。以降はこちらでお願いします。--Marine-Blue [ 会話履歴電信 ] 2011年3月1日 (火) 14:36 (UTC)[返信]

削除者

名称：削除者（規定の英語名は eliminator）
概要：削除に特化した機能割り当て

機能割り当て案1

ページの削除 (delete)
ページをまとめて削除 (nuke)
削除されたページを復帰 (undelete)
削除されたページの履歴や内容を閲覧 (deletedhistory, deletedtext)
削除されたページのタイトルを検索する (browsearchive)
版指定削除と版指定削除されたものの復帰 (deleterevision)
速度制限を受けない (noratelimit)
IPブロック適用除外 (ipblock-exempt)
権限付与/除去：管理者 or ビューロクラット

機能の説明：管理者に割り当てられた削除と復帰の機能をオプション制限なしで割り当てる形です。

青子守歌さんがおっしゃる通り、他の二者よりは面倒かもしれません。権限の付与や権限を付与された人の振る舞いに関するルールがややこしくなるかもしれませんが、先ずは割り当て案から考えましょう。機能案で検討すべき事項は管理者の削除機能を完全に切り分けるか、限定的にするかと言った感じでしょうか。

私個人としては機能をもう少し限定するとしても通常の削除＋削除版の閲覧はあったほうが良いと考えます。権限付与・除去は‥管理者に近い存在なので、ビューロクラットが良いのでしょうか。--Marine-Blue [ 会話履歴電信 ] 2011年2月23日 (水) 16:17 (UTC)[返信]

コメント まずは割り当て権限の議論をということなのでそちらに論点を絞ると、（#巻き戻し者でも述べた）「転送ページを作成せずにページを移動」(suppressredirect)も割り当てておいた方がよいと思います。少し込み入った削除、特に、特定版削除の場合にsuppressredirectは有用です（「ページの特定の版を削除/復元」(deleterevision)があるので、あまり使用頻度は高くないかもしれませんが）。suppressredeirectは削除権限の1種なので割り当てておいて問題ないと思います。--青子守歌（会話/履歴） 2011年2月23日 (水) 17:57 (UTC)[返信]

わたしも、suppressredirectはあったほうが良いかと思います。あと運用面での話に絡むのかと思いますが、削除タグ剥がしにより保護された項目の場合の特定版削除・版指定削除の場合をも対象にする場合は「保護設定を変更し、カスケード保護されたページを編集」(protect)が必要になると思われます。(保護された項目の特定版削除および終了判定は管理者のみの対応とするのであればprotectは要らないのでしょうが、この辺は運用面で調整が必要だと思います。)--Vigorous action （Ｔａｌｋ/History） 2011年2月25日 (金) 09:32 (UTC)[返信]

削除されたページの内容を閲覧(deletedtext)は削除した版を再確認するために必須だと思いますが、一方で過去に削除された内容を自由に見られるようなことになるのはまずいような。削除済みの記事の中には個人情報なども結構含まれているので、見ることができる人間が増えるのはあまり好ましくないように感じます。それなりの信任プロセスを経ることになるとは思いますが、それでも人数が増えると、故意なり偶然なりで情報が流れ出るリスクも増していくでしょう。例えば、自分自身が削除した版しか閲覧できない、のように制限が可能であれば良いのですが…。そうでなければOversightの導入とセットで考えていった方が良いように思いました。ちょっと脱線気味ですが、要はdeletedtextを単純に付与するのはまずいかな、ということで。--Bellcricket 2011年2月25日 (金) 12:36 (UTC)[返信]

コメント suppressredirectの追加に賛成します。protectについては確かに削除依頼への対応では不可欠ですが、どの程度まで削除者のハードルが下がるか不透明な状態ではあまり積極的に賛成できません。protectが必要な案件もそこまでたくさんあるわけではありませんので、管理者だけで十分だと思います。

deletedtextについては、undelete権限があれば同じことだと思いますが、どうでしょう？--W.CC 2011年2月25日 (金) 12:47 (UTC)[返信]

コメント 上で述べている事と重複しますが、巻き戻し者を巻き戻しに特化してsuppressredirectをこっちに持ってきたほうが良いかもしれませんね。

deletedtextに関してはW.CCさんのおっしゃる通り、undeleteがあれば一緒だと感じます。或いはdeleterevisionを外して削除版を見せないようにするとか？私個人としては、導入後が決まったならばオーバーサイトの方針整備を行っていきたいと思っています。方針をしっかりすれば立候補へ持っていけます（Bugzillaに何かを申請せずに運用を開始できる）ので。Bellcricketさんと考えが近いのでしょうか。

削除依頼の都合を考えればprotectも関係してくるのですが、加えると一気に幅が広がってしまうのが気になるところです。--Marine-Blue [ 会話履歴電信 ] 2011年2月25日 (金) 13:44 (UTC)[返信]

「削除された履歴項目 (関連する本文を除く) を閲覧」(deletedhistory)と「削除された本文と削除された版間の差分を閲覧」(deletedtext)についてですが、いっそのこと、このグループには復帰関連の権限を与えないという選択肢を選べば、割り当てる必要もなくなるのかと思います。ただ、この問題は削除者の導入どうこうという話以前の問題として、みなさんおっしゃってるような「オーバーサイト」(oversight)の導入の問題とも絡んできますし、あと削除内容の閲覧は場合によっては「編集フィルター編集者」(abusefilter)も見えることがある（c.f. WT:EF#ログの中に非公開情報が含まれる問題に対する対処）ので、ここで（現段階で）は気にする必要はないのではないかと思います。運用（権限付与）時には削除内容が見えることをきちんと理解してその責任を理解させることが出来れば、という条件がつくことは言うまでもないと思いますが・・・。--青子守歌（会話/履歴） 2011年2月27日 (日) 16:03 (UTC)[返信]

報告ページサイズが大きくなったため、Wikipedia:削除者とそのノートにまとめと続きを書きました。以降はこちらでお願いします。--Marine-Blue [ 会話履歴電信 ] 2011年3月1日 (火) 14:36 (UTC)[返信]

インターフェース編集者

名称：インターフェース編集者（規定の英語名は editinterface か interface editors）
概要：システムメッセージ、および関連する保護ページの編集を主眼とする

機能割り当て案1

システムメッセージの編集 (editinterface)
全保護されたページの編集、保護レベルは変更できない (editprotected)
他利用者のカスタムJS/CSSの編集 (edituserjs, editusercss)
ページの削除（復帰は出来ない） (delete)
IPブロック適用除外 (ipblock-exempt)
権限付与/除去：管理者 or ビューロクラット

機能の説明：保護されたページをすべて編集できます。削除権限を持ちますが、削除版の閲覧や復帰は出来ません。

mwのアップデートなどで色々なメンテナンス作業を行うと、その過程で時折不要なページが出るため、「削除」を加えた状態で提案しました。--Marine-Blue [ 会話履歴電信 ] 2011年2月23日 (水) 16:17 (UTC)[返信]

コメント 割り当て権限についてはこれで良いと思います。「ページを削除」(delete)および「「管理者のみ許可」の保護が設定されたページを編集」(editprotected)を「システムメッセージおよび関連ページ」以外で使用しないこと、という機能ではなく規則制限をしなければならない点が若干気にはなりますが、申請し実際に編集をする人はそれほど多くないでしょうし、相互監視は十分に効くだろうと思われます。「転送ページを作成せずにページを移動」(suppressredirect)もあると、ページ名を間違えたりしてページを移動しなければならない際にWP:CSD#リダイレクト4などを根拠に手間をかけずにリダイレクトを削除できますが、まぁこれについては強く推すつもりはありません。--青子守歌（会話/履歴） 2011年2月23日 (水) 17:57 (UTC)[返信]

suppressredirectを与えても特に問題ないと思います。--Vigorous action （Ｔａｌｋ/History） 2011年2月25日 (金) 09:32 (UTC)[返信]

コメント suppressredirectはあっていいかもしれませんね。賛成です。--Marine-Blue [ 会話履歴電信 ] 2011年2月25日 (金) 13:44 (UTC)[返信]

報告ページサイズが大きくなったため、Wikipedia:インターフェース編集者とそのノートにまとめと続きを書きました。以降はこちらでお願いします。--Marine-Blue [ 会話履歴電信 ] 2011年3月1日 (火) 14:36 (UTC)[返信]

その後

Wikipedia‐ノート:削除者、Wikipedia‐ノート:巻き戻し者、Wikipedia:インターフェース編集者の議論を踏まえてWikipedia:井戸端/subj/新しい利用者グループの作成についてが提出されました。--miya 2011年7月29日 (金) 22:50 (UTC)[返信]