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

概要

投票の目的: 各グループの導入そのものに対する賛否を問う
投票期間: 2011年8月15日 0:00 (UTC)から2011年8月22日 0:00 (UTC)まで
投票方法: 各グループの各選択肢にそれぞれ一人一回ずつ投票できます。
投票資格: 2011年8月12日 (金) 17:11 (UTC)時点で初投稿から1ヶ月以上、編集回数150回以上のログインユーザー

FAQ

井戸端で挙がったこと、或いはその他の場所で尋ねられたことをいくつかまとめておきます。

この提案の主旨は何？: →信任ラインを引き下げる案、インターン制として試しに暫く権限を付与する案、用途を限定して管理者立候補を行う事例などを考慮して考え出されたものです。管理者よりは若干低いハードルで削除などの権限を得られますが、使える機能に制約が加わります。なお、削除者のみ信任ラインが少し高くなる見込みです。
Eliminatorって名前はどこから出てきたの？: →既定の名称です。削除専用グループとして「Eliminator」と言う名前が予めシステムで割り当てられています。
方針が決まってないのに導入して運用するの？: →導入の是非と方針は別々に考えています。この場では純粋に「各グループを導入してよいかどうか」と言う基準での投票をお願いいたします。; →導入が決まれば方針の詳細をどうするか更なる検討が行われます。見送られれば方針議論が打ち切られ、導入を引き続き検討する場合には提案内容の見直しが求められることになります。
信任基準は厳しい、甘い、曖昧すぎるなど: →このページは導入そのものについての意見を問うものです。信任基準についてのご意見は各方針のノートでお願いします。
ここで方針に関するコメントを禁止するのはなぜ？: →話を拡散させないためです。書き込みする場所を絞らず投票コメントに紛れ込ませると、詳細を決定するときに大事な意見が見落とされるかもしれません。
各機能は管理者と同じ条件で使えるの？（例：削除依頼で管理者の代わりに削除者が対処することは出来るか）: →各機能が使える場面で行動に大きな制約は設けない予定です（ただし削除者はB-2案件に限り対処範囲から除外する提案が挙がっています）。

投票 (POLL)

巻き戻し者 (Rollbacker)

概要

管理者の巻き戻し機能を利用できる
巻き戻しをBotとして扱うことが出来る（ウォッチリストなどから隠せる）

機能割り当て

「特定ページを最後に編集した利用者の編集を即時巻き戻し」(rollback)
「巻き戻しをボットの編集として扱う」(markbotedits)
「自身の編集を自動で巡回済みにする」(autopatrol)
「速度制限を受けない」(noratelimit)

※方針や権限付与の基準についてはWikipedia‐ノート:巻き戻し者で決定されます。

導入に賛成 (support to implementation)

導入に反対 (oppose to implementation)

管理者による権限付与/除去 (grant/revoke rollbacker flag by sysop)

ビューロクラットによる権限付与/除去 (grant/revoke rollbacker flag by bureaucrat)

IPブロック適用除外に賛成 (approve IPblock-exemption)

IPブロック適用除外に反対 (disallow IPblock-exemption)

巻き戻し者についてのコメント

荒らし対処の役割を任せるのなら（現行管理者と同じ信任条件の下で）投稿ブロックなどの権限も併せて付与すべき。ブロック権限を任せられる程の信頼を得なくても巻き戻し権限なら与えるという発想自体に強い危惧を覚えます。提案趣旨どおりの方向性を前提とするなら、従来の管理者より低い信任条件で選ばれた巻き戻し者に対して、彼らが独断で行った処置の中立性と正当性を我々編集者が事後チェック・評価し責任を明らかにする手段をどのように保証してもらえるのでしょうか。他人の編集物・編集権に対する意識の持ちようが問われる案件だと思います。--ディー・エム 2011年8月15日 (月) 00:03 (UTC)[返信]
誤って巻き戻しを行ってしまう局面も多いため、この利用者グループの作成には積極的に賛成できません。--Himetv 2011年8月15日 (月) 01:37 (UTC)[返信]
- 誤操作に関しては個人差だと思います。私はカスタムスクリプトで巻き戻しリンクを二倍に増やしています（通常の巻き戻しリンクとbot扱いの巻き戻しリンク）が、リンクを増やしてから誤操作が出たことは一度もないです。それに巻き戻しの機能を各利用者が求めるかどうかは選択肢ですし、巻き戻しリンクが表示されることによる誤操作を回避したい人は権限を申請するんでしょうか。--Marine-Blue^{talk✿contribs✿mail} 2011年8月16日 (火) 17:07 (UTC)[返信]
差し戻しは特別な権限がなくても誰にでもできますし、ナビゲーション・ポップアップのように、それを1クリックで実現できるようなスクリプトも存在します。改めて権限として入れることによるメリットやデメリットがあまり見えないので、コメントにとどめます。--Jkr 22 55 2011年8月15日 (月) 02:02 (UTC)[返信]
rollbackだけでなくmarkboteditsも付与されるので、一定のメリットはあると考えて賛成します。（実際に立候補する方が出てくるかどうかがわかりませんが・・・）KMT 2011年8月15日 (月) 09:37 (UTC)[返信]
荒らし対応という意味では投稿ブロックもセットにしないとあまり意味は無いのではないかと考えますので、賛成はしません。--Haifun999 2011年8月15日 (月) 09:44 (UTC)[返信]
荒らしによる差し戻しの際に「巻き戻しをボットの編集として扱う」(markbotedits)があると、特別:最近の更新から荒らし投稿の差し戻しを隠す事が出来るため一定の効果があると考えます。--Vigorous action （Ｔａｌｋ/History） 2011年8月16日 (火) 08:49 (UTC)[返信]
誤操作だけでなく、要約欄が記入できないことによる説明不足、安易な使用による不適切な荒らし呼ばわりなど、管理者のロールバック機能には過去に問題視された事例があります。敢えてロールバックを頑張っちゃうようなグループをつくるのは賛成できません。管理者権限を削除対応と荒らし対応に分けるのでしたら、後者は保護とブロック（と必要に応じてロールバック）に専念していただくのが効果的かと思います。--Noche de la pena 2011年8月19日 (金) 15:14 (UTC)[返信]
数十件におよぶ大量荒らしの対処をするとき、即時削除できるものは即時削除し、過去版に戻すべきものはロールバックします。削除者がロールバック権限もほしいと感じたら求めることができるように、この機能も導入しておいたほうがいいと思います。--miya 2011年8月19日 (金) 22:10 (UTC)　追記：おととい書き忘れましたが、ロールバック機能は、同じ荒らしが同一ページを連続版で荒らした時に、１クリック直前ユーザーの版まで一気に戻せるところが効果的です。「取り消し」だと1版ずつしか戻せませんので。--miya 2011年8月21日 (日) 04:49 (UTC)[返信]

削除者 (Elliminator)

概要

通常の削除と復帰、版指定削除とその復帰が可能な、管理者から削除機能だけを抽出した利用者
削除版を見れるユーザーが増えることになるものの、問題が大きい削除版はオーバーサイト権限を使うことで削除者・管理者から秘匿できる
- 2011年8月9日より二名の管理者がウィキペディア日本語版のオーバーサイトに就任

機能割り当て

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

※方針や権限付与の基準についてはWikipedia‐ノート:削除者で決定されます。

導入に賛成 (support to implementation)

導入に反対 (oppose to implementation)

管理者による権限付与/除去 (grant/revoke elliminator flag by sysop)

ビューロクラットによる権限付与/除去 (grant/revoke elliminator flag by bureaucrat)

IPブロック適用除外に賛成 (approve IPblock-exemption)

IPブロック適用除外に反対 (disallow IPblock-exemption)

削除者についてのコメント

削除依頼の対処が管理者さんの負担になっていると感じますので、削除者さんが増えたらそういうところが軽減されると考え賛成します。--長月みどり 2011年8月15日 (月) 19:43 (UTC)[返信]
削除依頼の対処などの削除関係の処理には履歴の精査などかなり確認事項が多く時間がかかります。実際削除依頼の対処中などはRCの監視との両立はかなり難しいため、対処していただける方が増えるのは助かります。--Vigorous action （Ｔａｌｋ/History） 2011年8月16日 (火) 08:49 (UTC)[返信]

インターフェース編集者 (Interface editors)

概要

システムメッセージやそれと同等の役目を果たすページの編集を許可する
システム関連においてのみ保護ページの編集行為が認められる

機能割り当て

「ユーザーインターフェースを編集」(editinterface)
「「管理者のみ許可」の保護が設定されたページを編集」(editprotected)
「他の利用者のJavaScriptファイルを編集」(edituserjs)
「他の利用者のCSSファイルを編集」(editusercss)
「ページを削除」(delete)
「転送ページを作成せずにページを移動」(suppressredirect)

※方針や権限付与の基準についてはWikipedia‐ノート:インターフェース編集者で決定されます。

導入に賛成 (support to implementation)

導入に反対 (oppose to implementation)

管理者による権限付与/除去 (grant/revoke interface editor flag by sysop)

ビューロクラットによる権限付与/除去 (grant/revoke interface editor flag by bureaucrat)

IPブロック適用除外に賛成 (approve IPblock-exemption)

IPブロック適用除外に反対 (disallow IPblock-exemption)

インターフェース編集者についてのコメント

編集フィルターの権限も管理者が着脱できるので、それに準じて管理者が権限操作をするのがいいと思います。--Jkr 22 55 2011年8月15日 (月) 02:18 (UTC)[返信]
インターフェースの編集については全利用者に影響を与えるため。一定以上の知識が必要を持つ方であれば管理者にこだわる必要が無いと思います。また管理者のすべてが一定以上の知識を持つわけでもないためインターフェースについて理解のある方が増え編集していただけるほうが安全であると考えます。--Vigorous action （Ｔａｌｋ/History） 2011年8月16日 (火) 08:49 (UTC)[返信]
将来管理者権限のうち、システムメッセージに関する編集権限を切り離すことができる第一歩になると考え、導入に賛成します。--Himetv 2011年8月21日 (日) 10:22 (UTC)[返信]

投票全体についてのコメント

上記のFAQに「ここで方針に関するコメントを禁止するのはなぜ？」とありますが、投票ルールにその記載が無いので、具体的にどういうコメントを禁止しているのか判断が付かず戸惑いました。導入決定を前提とした方針の具体案提示を禁止するという意味だと思いますが、それで良いのでしょうか？--ディー・エム 2011年8月15日 (月) 00:03 (UTC)[返信]
- 上手に説明できておらず申し訳ありません。仰る通りの趣旨で間違いありません。何でもかんでも方針のノートへ行けと言っている理由の説明として書いております。実際の運用案と言ったほうが良かったかもしれませんね…。--Marine-Blue^{talk✿contribs✿mail} 2011年8月16日 (火) 11:44 (UTC)[返信]
まず提案趣旨において、同じ権限行使をする担当者間で信任ハードルに落差を設けることを当然視する発想に強い違和感を持ちます。特定分野専門の管理者グループを新設してより多様な人材確保を促進するという趣旨であればそもそも一部の権限行使者だけ信任ハードルを差別化する必要はないですし（根拠も無いですし）、もし仮に各管理者権限に対する信任条件の緩和をコミュニティが支持するのなら従来の管理者も含めて条件緩和した方がより多く管理者を増やせます。その点で合理性にも疑問があります。--ディー・エム 2011年8月15日 (月) 00:03 (UTC)[返信]
- グループ権限のうち『全員』・『利用者』と『自動承認された利用者』以外の特殊な権限グループはそのグループに与えられた権限を使用するに値する(濫用しない)であろうという程度にコミュニティから信任されていると思われる利用者にすぎません。その特殊な権限の種類（重要性・危険性など）により信任基準に差があっても問題は無いと思います。実際一般の利用者では制限された機能（「API要求でより高い制限値を使用」(apihighlimits)・「転送ページを作成せずにページを移動」(suppressredirect)・「自身の編集を自動で巡回済みにする」(autopatrol)・「速度制限を受けない」(noratelimit)など）を使用出来る特殊権限グループであるBotなどは、一定期間反対票が無いか少ない・実際の作業内容・オペレーターの言動などを考慮して付与する事になります。ディー・エムさんの言っておられる内容ですと、Botグループに変更する場合も管理者と同等の基準での審議という事になり現状その基準で日本語版で権限付与されたBotが無いという事になります。--Vigorous action （Ｔａｌｋ/History） 2011年8月21日 (日) 05:28 (UTC)下線部を追加--Vigorous action （Ｔａｌｋ/History） 2011年8月21日 (日) 05:32 (UTC)[返信]
  - 仮にボットの権限を分与するという提案であれば、管理者の信任条件とは関係なく、ボットに対してコミュニティが課している信任条件に基づけば問題ないと思います。他方、管理者の主要権限の一部を付与するということであれば、基本的には当該権限に対する現行の信任条件を適用するという考え方が本筋かと思います。もし信任の条件変更についてきちんとした根拠の提示があるならば、信任条件を緩和するとしても差し支えはないと思います。たとえば現行管理者の権限のうち削除関連の権限がその他の管理者権限よりも運用の安全性に優れると判断すべき根拠（こっちの管理者権限には75%の信任条件が要るがこっちの権限には要らないという区別）が存在するのであれば、削除者の信任条件ラインを緩和する理由付けになるとは思います。（もう投票自体は済なので若干踏み込んで言及しますと）要するに、考え方によってはその可能性（特定の管理者権限の信任ラインを下げられる可能性）があるとしても、それは説明不要なほど自明の事柄ではないし、そのことが自明でないと認識した上で制度設計を構築していかないと、結果として出来上がったシステムの妥当性を担保できないのではないかと。--ディー・エム 2011年8月23日 (火) 15:17 (UTC)[返信]

投票結果まとめ

巻き戻し者: ある程度の賛成票があり、過半数となるため「導入」、付随する条件は「ビューロクラットによる権限変更、IPブロック適用除外」として今後の作業を進めたいと思います。; ただし、これに関してはどちらにもつかない意見が少なからずあるため、方針の決定や運用に一層の慎重さが求められると考えております。
削除者、インターフェース編集者: とくに反対票はないため両方とも「導入」、付随する条件は「ビューロクラットによる権限変更、IPブロック適用除外」として進めたいと思います。

投票結果まとめが遅くなって申し訳ないです。--Marine-Blue^{talk✿contribs✿mail} 2011年9月3日 (土) 13:10 (UTC)[返信]