Web Analytics

See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Wikipedia‐ノート:管理者の辞任 - Wikipedia

Wikipedia‐ノート:管理者の辞任

出典: フリー百科事典『ウィキペディア(Wikipedia)』

あなた宛の新しいメッセージが届いています(差分)。

過去ログ

関連

目次

[編集] 「管理者の解任」規定の正式化に向けての提案

現在、Wikipedia:管理者の解任の正式化に向けての準備を進行中です(Wikipedia‐ノート:管理者の解任#公式化のための投票に向けて)。それに先立ち、Wikipedia:管理者の辞任について、次の2点の修正を提案いたします。この提案自体は特に新しいことを決めるものではないため、72時間〜1週間程度待ってご意見やご異論がなければ、私の方で規定を追加します。コメント等をお待ちいたします。--Anonymous000 2006年11月8日 (水) 13:53 (UTC)

[編集] 「管理者の解任」規定の追加等

(修正履歴)下線部追加・想定される質問-「当面は」とは?→コミュニティで議論して新たに合意するまでです。「当然の規定」なのでトルでもいいです。--Anonymous000 2006年11月20日 (月) 14:01 (UTC)

Wikipedia:管理者の解任が、Wikipedia:管理者の辞任#管理者が辞任すべき理由の2番(「他の参加者が、以下のような理由で、管理者に辞任してもらうことを望む」)の理由があるかを決めるの具体的手続であることを、Wikipedia:管理者の辞任#退任とその手続きの節に、次のように加える(Wikipedia‐ノート:管理者の解任#管理者の辞任との関係→手続の新設も参照)。--Anonymous000 2006年11月8日 (水) 13:53 (UTC)・ビューロクラット推奨に修正

  • (文案)

===他の参加者が管理者の辞任を望む場合===

  • Wikipedia:管理者の解任の規定に従って、手続を進めてください。この規定は、管理者自らがコミュニティの信任を問いたいときにも用いることができます。
  • 「管理者の解任」に基づく有効な「投票結果の確定」により当該管理者を解任することが確定し、かつポータルにその結果の告示が行われた後に、m:Requests for permissionsでのm:スチュワードへの依頼により、退任処理を行います。この場合、メタで活動履歴のある管理者(当面はメタに信頼されたビューロクラットが推奨される。ただしメタに信頼されたユーザーであれば管理者であることを問わない)が、メタへの依頼を行うものとします。


  • (順番の変更)

Wikipedia:管理者の辞任#退任とその手続きの下の節の順番を、Wikipedia:管理者の辞任#管理者が辞任すべき理由に併せて変更する。具体的には、

Wikipedia:管理者の辞任#自発的な辞職についてWikipedia:管理者の辞任#他の参加者が管理者の辞任を望む場合(新設)、Wikipedia:管理者の辞任#自動退任について

の順に変更する。

  • (日本語版ローカルでない職を辞任する場合の除外規定の位置の変更)

現在Wikipedia:管理者の辞任#自動退任についての下にある「ただし、ウィキメディア財団理事、開発者、スチュワードの職にあるものはこの例外とする。」とする規定を削除し、「なお、日本語版のコミュニティの信任で選任されるのではない、ウィキメディア財団理事、開発者、スチュワードの職に関する辞任手続については、この『管理者の辞任』が規定する辞任理由及び手続の効力は及びません。」と変更の上で、記載位置を冒頭部分に変更する。

[編集] ビューロクラット・チェックユーザーの権限を持つ管理者が辞任した場合、その権限も同時に失うことの明文化

ビューロクラット、チェックユーザーの権限を持つ管理者が辞任した場合に、ビューロクラット、チェックユーザー権限も同時に失うことを明文化しておく([[Wikipedia‐ノート:管理者の解任#ビューロクラット、チェックユーザーへの準用は?の1.に関する議論を参照)。--Anonymous000 2006年11月8日 (水) 13:53 (UTC)

Wikipedia:ビューロクラット#ビューロクラットにできることの規定を読み直し、ビューロクラットには管理者を普通の利用者に戻す権限がないことに気づきましたので、文案の中の管理者の辞任手続を行なう「ビューロクラット」を「スチュワード」に変更しました。--Anonymous000 2006年11月9日 (木) 00:21 (UTC)

Wikipedia:管理者の辞任#退任とその手続きの次に、次の一節を加える。

  • (文案)

=== 管理者が辞任した場合 ===

理由の如何を問わず、管理者が辞任した場合、その権限を持つスチュワードが管理者の辞任手続をとります。辞任した管理者がチェックユーザー権限またはビューロクラット権限も有していた場合、それらの権限も失います。

この変更提案の意図そのものは反対しませんが、文案はちょっと考えさせてもらってもいいですか?日本語版専門のスチュワードというのは存在しないのに、たまたま日本語版の管理者とスチュワードを兼任されている方が存在することで、スチュワードという表現をここで使用することによって、例えば辞任したい日本語版の管理者の方が、その方(スチュワード)の日本語版の利用者ページに依頼を書いたりしても、スチュワードの方は困ることでしょうから。--Californiacondor 2006年11月11日 (土) 15:02 (UTC)
了解です。文案確定に関する議論へのご参加(一番下で進行中です)をお待ちしています。移動も完了しました。ご承諾に感謝します。--Anonymous000 2006年11月12日 (日) 03:43 (UTC)・下線部追加--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

[編集] 管理者を辞任することが決定した後の手続について

ご提案の内容がWikipedia:管理者の解任の正式化と直接の関連性がない自動退任に関する規定が主であること、及び、「新しいことを決めるわけではない」という上記の2提案とはかなり色彩が異なること等から、勝手ながら節を分離させていただきました--Anonymous000 2006年11月9日 (木) 15:09 (UTC)

[編集] 「退任とその手続き、自動退任について」の修正

メタのRemoval of accessを読んで、メタの該当する項目の記述とここの退任とその手続きでの記述の間に内容の相違があることに気づいたのでここへやってきました。参考までにWikipedia‐ノート:管理者の解任に書き込みをしておりますので宜しかったらお読み下さい。

「退任とその手続き-自動退任について」の4番では、

  • 「Stewardに依頼し、退任処理を行う。依頼はメタ・ウィキメディアのm:Requests for permissionsで行う。metaのルールにより、日本語版でsysopをしておりmetaでも活動履歴があるユーザーが申請を行う」

となっておりますが、該当するメタのページによりますと、管理者本人の自発的な管理者権限返上手続き以外に対しては、“local wiki(原文そのまま)”で合意形成の後、“a trusted person from that wiki should just provide a link here to the discussion and a very brief explanation of the reason for de-adminship and results of discussion”となっています。簡単に意訳しますと「(合意形成が行われたローカル版)ウィキの信頼できる人物が、合意形成のなされたページへのリンク、簡単な退任(解任)の理由説明、論議の結果だけをここに記して下さい」ということになっています。つまり、合意形成後にメタでスチュワードに手続きを依頼する人物は日本語版でsysopをしている人物とは限っていません。またメタでの条件を満たすためにも合意形成を行う場を明確化したほうが良いと思われるので、退任の手続きの定めを下記のように修正することを提案いたします。

  • (文案)
  1. 管理者の辞任管理者の自動退任項目において、どのユーザーも管理者が継続的に3ヶ月間以上活動歴のないことを指摘することが出来きます。ただし虚偽に基づく申告は無効となります。
  2. 継続的に3ヶ月間以上活動歴のないことを他のユーザー1名が確認し、管理者の自動退任において確認した旨を記入して下さい。誰でも確認が出来ます。ただし虚偽に基づく申告は無効となります。
  3. 確認を行ったユーザーまたは気づいたユーザーがWikipedia:コミュニティ・ポータルのTemplate:意見募集中等で自動退任の手続きに入ったことを公く告知下さい。当該管理者のユーザー・ノートでも自動退任の手続きに入ったことを記入することが推奨されます。
  4. 同時に、確認を行ったユーザーまたは気づいたユーザーは、コミュニティの合意に基づいた手続きによって自動退任が執行されることを管理者の自動退任に記入して下さい。
  5. メタ・ウィキメディアRequests for permissionsスチュワードに依頼し、退任処理の依頼を行って下さい。メタのルールにより、日本語版で信頼されているログイン・ユーザーで、メタ・ウィキメディアでもアカウントがあるユーザーが依頼を行って下さい。

なお、「信頼されている」という表現は大変抽象的な観念ですが、訳語であるための表記の揺れそのものはここで討議しても結構ですが、「もっと明確にして欲しい」「違った条件を課したい」などのご意見は、その表現を採用しているメタ・ウィキメディア該当ページノートで行うようお願い申し上げます。--Californiacondor 2006年11月8日 (水) 23:15 (UTC)

(質問)Californiacondorさまが援用されているm: Requests_for_permissionsでは、その冒頭部で、ローカルの手続を持たない言語版ないしプロジェクト ("for all Wikimedia wikis which do not have a local permissions procedure.") での手続を定めるいわば「一般法」的な文書であることが記載されています。そして、ビューロクラット職があるローカルでは、そのローカルが定めた手続をいわば「特別法」として用いることを明文( If your wiki has a bureaucrat, please use the relevant local request page instead.)で定めているように思います。従って、ビューロクラット職がある(そして実際にいる)日本語版ウィキペディアで管理者就任や辞任の手続を定めればそちらが優先される、言い換えれば、日本語版ローカルの手続を「m: Requests_for_permissionsに合わせる」か否かは、あくまで日本語版ウィキペディアの中で決める事柄であるように思われるのですが、いかがでしょうか?--Anonymous000 2006年11月8日 (水) 23:54 (UTC)

相変わらず素早いご意見ご質問投稿ありがとうございます。実は私も最初はそのメタ・ページの冒頭の記述を読んで、Anonymous000さんと同様の理解をしておりました。が、

  • Bureaucratビューロクラットによれば、ビューロクラットにできることは、
    • 他の利用者を管理者にする
    • 管理者をビューロクラットにする
    • 利用者のアカウント名を変更する
    • ボットステータスを付与/剥奪する
    • 管理者権限の行使
とあって、新しい管理者をメタにあるフォームを使って登録することは出来ても、“管理者の権限を取り去る”のはビューロクラットの権限ではない。システム的にも新しい「新管理者の登録」のように、フォームを使ってビューロクラットが管理者の権限を取り去るシステムになっていない、つまりビューロクラットがローカルで処理できるようにはなっていません。
  • “Please use the relevant local request page instead”の意図は、要はメタのRequests_for_permissionsページで論議はしてくれるな、まずローカルで合意形成をして、ローカルで処理できることは処理して下さいということだと思います。これはコミュニティの自治を尊重しているのと、これだけプロジェクトが多くなってしまった今、メタでそのようなことを全部論議したら膨大な量になって収拾が付かなくなるという現実的運用問題に対処するためだろうと思われます。またスチュワード自身が依頼の判断を下すのでなく、彼(女)らは、依頼と依頼者の有効性正当性を検証し、有効な依頼なら手続きをするだけですし。それから重複になりますが、合意形成に至るまでの方法はメタは関知していませんし、ローカルがメタに「合わせる」必要はありませんし、私もそのようなことは主張してはいません。
  • が、ローカルで合意形成で手続きを定めて、その結果管理者が退任若しくは解任という結果になっても、前述のように“管理者の権限を取り去る”ということはビューロクラットは出来ません。ですから誰かがRequests_for_permissionsにおいて“管理者の権限を取り去る”権限があるスチュワードに対して依頼の書き込みをしないといけないのですが、そこで、Removal of accessの「信頼できる人物云々・・」という表記に行き当たるわけです。スチュワードが望んでいるのは結果報告です。ローカルでちゃんと合意形成が出来ており、かつスチュワードがそれをちゃんと確認できるのなら、依頼の書き込み自体はビューロクラットでも管理者でもなくてもいいと思います。この部分はローカルで解決できないことなのでメタのルールに従うべきだと考えます。ちなみに自発的な辞任は当該管理者本人が書き込むこととなっていますので混乱なきよう(実際今まではガイドラインに忠実に従っていたわけではないようですが)。

tanuki_Zさんが署名に(sysopは偉くない)と入れていらっしゃいますが、メタでの依頼の書き込み自体はビューロクラットでも管理者でもなくてもいいという考えは、管理者は利用者にない権限を持ってはいても、利用者を代表したり、上に立つ立場ではないという理屈にも合っていると思います。重要なのは誰がスチュワードに報告(依頼)しにいくかではなくて、ローカル・コミュニティでの合意形成とそれに至ったプロセス、理由、そして結果を事実的に文書としてローカルのページのどこかに記録することの方です。結果的にはメタでの依頼のために記録を残す必要があるので、合意形成のプロセスに影響が及んでいることは認めますが、核心の部分はメタは全く関係ありません。それから、もちろんビューロクラットや管理者からの報告の方がスチュワードにとっては報告者の信頼性チェックが容易なことから、手続きが少しだけスムーズに運ぶ可能性は認識しております。

もちろん信頼ある人としているのは、虚偽の書き込みに対応するのと、小さな言語版ではビューロクラットがいないことが多いし下手すると管理者が全員いなくなってしまう事態に備えてのことでしょう。が、虚偽の書き込みに対しては、スチュワードはそんな書き込みを鵜呑みにしたりだまされたりするような方々にはお見受けしません。あまり常軌を遺脱した行動が続くと、目立つ役職なので理事の目にも留まることから、相互チェックは結構シビアさだと思うので、粛々と依頼の事実検証と手続きをしてくれることでしょう。さらに、虚偽の書き込みをm:Requests_for_permissionsで書こうものなら、スチュワードだけでなく、メタの世界各国の精鋭sysopが“お相手”してくれることでしょう。第一、メタにはマルチリンガルな方々が沢山いるので、彼(女)らがコミュニティでの合意形成が本当にあったかどうか、虚偽の書き込みかどうかは、普段は日本語版に来ていなくても、日本語版の当該ページをしっかり訪れてチェックしてくれることでしょうから(依頼には合意形成が行われたページへのリンクが必要です)、日本語を解するスチュワードがたまたま不在でも、依頼に疑問点や不備があれば日本語を解さないスチュワードにも英語でちゃんと報告がいくことでしょう。メタの規定と相違がなければ、確かに「メタに報告に行くのはビューロクラットにしましょう」と日本語版の「特定法」を決めることも可能ですが(ビューロクラット=信頼のある人でしょうから)、上記の理由からユーザーが依頼しても支障がないと思うのです。--Californiacondor 2006年11月9日 (木) 04:37 (UTC)【修正--Californiacondor 2006年11月9日 (木) 14:29 (UTC)】

下にコメントしました(編集競合しました。)--Anonymous000 2006年11月9日 (木) 15:09 (UTC)

[編集] 管理者解任制度との関係で

節を分けさせていただきました。スチュワードしか権限を剥奪できないという点について、私の理解の誤りをご指摘いただきありがとうございました。

辞任が決まった後の具体的手続、つまり、ある管理者の解任をコミュニティの合意で決めた場合(自動退任の場合や、自らmetaで依頼しない管理者の自発的辞任の場合も同じ)に、誰が、どのタイミングで、スチュワードによるde-adminshipを求めるか、という問題ですよね。この点について、私の考えでは、(1)日本語版ウィキペディアでのこれまでの自動退任のプロセス(または自発的辞任プロセス)がどのように処理されてきたか、(2)これまでの処理で何らかの問題が発生していたか、ということをもう少し検討しなければ、Californiacondorさまご提案の手続で決めてよいかどうかの判断が困難です。つまり、「これまで特に問題が生じていないのであればこれまでのどおりの処理を行なえば足りるし、もし明文化するとしてもそれに合わせればよい。もし仮に、すでに問題が生じていたのであればそれを解決するための手段を考えて明文化する必要がある」と考えます。

また、辞任が決まった後のローカルからメタに連絡する具体的手続を明文化する際には、Californiacondorさまもお考えの通り、「信頼できるユーザー」を余りにも広げすぎることでmetaに荒らし同然の迷惑行為を行なうユーザーを日本語版から出してはいけないという配慮(ローカルからmetaまで行って精鋭sysopらの無用なお相手をさせることを招くような規定はそもそも作るべきではないというのが私の考えです)と、速やかに解任手続を完了させる必要があるという要求とのバランスをとることが必要になります。このため、「信頼できるユーザー」を合理的な範囲に限定する必要があるわけですが、それを例えばローカルのビューロクラットに限定するのか、動議提出者または動議賛同者に限って提出を認めるのか、管理者に認めるのか、当該投票に賛成したユーザーに認めるのか、投票と無関係でも一定の一般ユーザーにも認めるのか、さらには、時期を段階的に決めておいて、ある者(例えばビューロクラット)が一定期間(例えば48時間以内)に対処しない場合に限りより広く(例えば動議提出者及び賛同者)認めていくのか、など、考えただけでも頭が痛くなるくらい検討することがたくさんあります。

そもそも、管理者解任制度の正式化を図っている私が言うのも何ですが、正式化したあとに解任制度が利用されたとしても、実際に解任される管理者はほとんどいないのではないかと、私は予測・期待しています(その理由は、私自身の考えとして、もう少し成長してほしいと思う管理者はいますが、解任を求めたいほど問題があると考えている管理者は、現時点ではいないからです)。つまり、管理者の解任が決まった後の手続を明確化しておくというのは、私の見込みが外れた場合の手続を決めようということであり、正直なところ、「棚上げ」(ある程度事例が集積してから必要に応じて明文化)でいいのではないかというのが本音です。もちろん、従来の日本語版ウィキペディアにおける自動解任等の具体的手続やその問題点をよくご存じのユーザーを交えてこの点を明確化しておく方がいい、ということであれば、「備えあれば憂いなし」ともいいますので、是非お願いしたいと思います。ということで、個人的には管理者解任制度の正式化の前に、この議論について私の意見をこれ以上述べることは、恐れ入りますが、今の状況のままであれば(つまり既に生じてきた問題点が具体的に明らかにならない限りは)差し控えさせていただきたいと思います。--Anonymous000 2006年11月9日 (木) 15:09 (UTC)

[編集] 辞任が決定した後のスチュワードへの依頼方法の具体化

Wikipedia‐ノート:管理者の解任より移動しました--Anonymous000 2006年11月12日 (日) 03:37 (UTC)・節分けしました。お気づきの点があれば切る場所や節の名前などを変えていただいてもかまいません。--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

[編集] 具体化の提案

節を分けました--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

こんにちは。Toki-hoと申します。丁寧な議論の積み重ね拝読しております。関係者のみなさまありがとうございます。ひとつ素朴な疑問があるのですがよろしいでしょうか。管理者の解任が成立した場合、スチュワードが管理者権限の剥奪をおこなうことになると思うのですが(Wikipedia:ビューロクラットm:Stewards)、その場合だれがどのようにスチュワードに連絡するのでしょうか。そうなった場合日本語のわからないスチュワードにしっかりコミュニティーの意思を伝える方法をあらかじめ用意しておかないと、せっかくの解任規定が有効にはたらかない可能性があると思いますので質問いたします。よろしくお願いいたします。(なお質問の場所が不適切でしたら移動してください)--Toki-ho 2006年11月8日 (水) 23:26 (UTC)
Toki-hoさま、ご質問ありがとうございます。Californiacondorさまから、Wikipedia‐ノート:管理者の辞任#「退任とその手続き、自動退任について」の修正というご提案もされており、関連する話題と考え、Wikipedia‐ノート:管理者の辞任#管理者解任制度との関係でに私の考えを投稿しています。要約すると、確かに遅延のおそれを防止するには決めておくと確実だとは思います。しかし、これを検討するためには、遅延防止のためにとる方法のデメリットの検討が必要になります。また、従来の日本語版ウィキペディアが自動退任等の際にどのような処理を行なってきたか、またそれで何らかの具体的な問題が生じていたのか、を明らかにする必要もあります。正直なところ、私自身は、管理者解任制度が正式化したとしても、それほど多くの管理者が解任されるとは考えにくいと予測しています。このため、実際に解任されることになるとしてもごく少数にとどまるであろう管理者のために、予め多くの点を検討して手続を明示しておく必要性は、現時点では低いのではないかと考えています。もちろん、私の予測が外れたり、少数であっても遅延などの問題が生じてくるようであれば、そのような問題に対応するために、具体的手続を明文化する必要があるかもしれません。結局、少し事例が集積した後で必要に応じて対応する(つまり「棚上げ」)のでいいのではないかな、私自身は考えています。もっとも、Californiacondorさまは、この点をきちんと作ってはどうかというご提案をされていますので、もしご興味があれば、Wikipedia‐ノート:管理者の辞任#管理者を辞任することが決定した後の手続についての方で議論を進めていただくと、私も憂いがなくなって助かります。また、もしこれまでに辞任等の過程で実際に生じてきた問題がすでにあるようであれば、話は別となりますので、ご存じであればお知らせいただけますと幸いです。(追伸)Toki-hoさまのご指摘をいただき、Wikipedia‐ノート:管理者の辞任#ビューロクラット・チェックユーザーの権限を持つ管理者が辞任した場合、その権限も同時に失うことの明文化を修正しました。このあたりになってくると、まだ若葉マークも取れていない私の知識は非常にあやしいので、誤りのご指摘を頂くととても助かります。ご指摘ありがとうございました。(署名付記)--Anonymous000 2006年11月9日 (木) 15:13 (UTC)
Toki-hoです。Anonymous000さん、さっそくのおこたえありがとうございます。ご意図了解いたしました。ポイントしていただいたページのCaliforniacondor さんのご意見も拝読しました。そのうえで、ちょっと敷衍した議論をさせていただきます。なお、あらかじめ申し上げますが、これから申すことにが十分議論ずみであるなら申し訳なく、その場合はどうぞご容赦くださいませ。さてこの「管理者の解任」ご提議は、現行の「管理者の辞任」における、「他の参加者が、以下のような理由で、管理者に辞任してもらうことを望む 」場合についての規定(1.その提議は多分コメント依頼でおこなわれ、2.どういうふうに議論をすすめるのかはわからないがともかくそのコメント依頼で当該管理者をやめさせることがコミュニティーのコンセンサスとして決定すれば、3.だれがどうやってスチュワードに管理権限剥奪を申し出るのかあらかじめ決められていないが、多分当該管理者自身がメタにいって自分自身で辞任を申し出ていただく)が、有効にはたらいていないor非常にわかりにくいなどの理由からなされたものと存じます。言葉をかえていうと、現行の「管理者の辞任」では、コメント依頼においてなされるはずのコミュニティーの合意と、それにもとづいてなされるはずの当該管理者の「辞任」を、よりシステマティックなかたちにするための「管理者の解任」のご提議と理解しております。で、うえの()内の1.2.は現在おつくりいただいている案で十分論議され、おおかたの納得が得られるのではないかと存じます。ただし、ネックは3です。現行のコメント依頼方式でもたとえ1.2.が実現したとしても、はたして3が聞き届けられるかどうかに「管理者の辞任」の有効性が問われているのではないでしょうか。現行は日本語版の管理者の自動退任などは、唯一日本語がわかるスチュワードのsuisuiさんがしておられると思うのですが(未確認ですが。。)、たとえばsuisuiさん自身に管理者の解任が決定された場合どのような状況になるのかが不明です。そのあたりがはっきりしないかぎり、現在ご提議していただいてる案は、やはり現行の方式とおなじく「形式的なもの」とうけとられはしないでしょうか。つまり「どうせ解任動議をだしたとしても結局はそれが現実のものにならないのではないか」という疑義があるかぎり、たとえは悪いですが「ざる法」的なものとしてうけとられるのではないでしょうか。もしそうであれば、せっかくのここでのご提議が無駄になると思うのです。ですので、そのための具体策として、メタに対する根回しをあらかじめしておく必要があるのではないかと、私は思います。つまり、日本語版でこういう解任の手続きが話し合われているが、これが公式化した場合、どういう書式で申し入れれば、日本語がわからないスチュワードでも、機械的に処理してくれるかという質問からはじまると思いますが。以上は、ポイントしていただいたWikipedia‐ノート:管理者の辞任#「退任とその手続き、自動退任について」の修正Wikipedia‐ノート:管理者の辞任#管理者解任制度との関係でを拝見したうえで申しております。各論はそちらでの議論かもしれないとは思いつつ、投票にうつられる前に私自身が問題と感じるところを申し述べておいたほうがよいと思い、書かせていただきました。つまるところ、Anonymous000さんのおっしゃる「棚上げ」のメリット、デメリットを考えた場合、わたしはデメリットのほうが多いと思うということです。その部分を棚上げしたままですと、この案そのものの信頼性が現行のものと結局は同じになるのではないかというデメリットです。もちろんみなさまがメリットの方が多いと判断なさるのでしたら、それに従い、「棚上げ」に賛成いたします。以上、長くなりましたがこの点についての議論をよろしくお願いいたします。Toki-ho 2006年11月10日 (金) 02:39 (UTC)

[編集] メタでの処理に関する現状調査等

節を分けました--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

stewardsは自分が元来参加しているローカルのプロジェクトでのsysopの権限与奪に付いて、原則行わないことになっています。現実的にはbcratと兼任も多いので奪に関してになりますが。タイミング的に時間が空いている場合でもsteward間で適度にコミュニケーションをとってローカルのプロジェクトについては自分で行わないことを原則としています。そのため私にはja.wikiでの奪の権限行使は緊急の場合を除いてないものと考えてください。今まで行ったこともありません。誰からの依頼でも機械的に権限与奪を行うことはしません。arbcomがないプロジェクトについてはコミュニティの合意があることを前提として依頼者のmetaでの活動履歴は最低限参照します。ほとんどの場合stewardsは自分の知らない言語で行われた議論や投票、投稿履歴を参照することになるため、現実的な選択肢としてIRCで依頼者や本人、あるいは各プロジェクトに詳しいユーザーや翻訳できるユーザーにヒアリングを行います。これはstewardsに大きく負荷のかかる作業であり、この方針を一生懸命作ってこの方針を元に管理者のdesysopが増えることには私は反対よりです。この方針ができたとしてもarbcomができるまでの一時的なルールにしかならず、toki-hoさんがおっしゃっているのとはちょっと意味が違いますが、ここでの議論に時間を注いでもあまり実りある結果は得られません。力のかける方向が間違っているように感じます。arbcomを設立させれば逆にstewardsが機械的に近く処理できるようになるため、実行に現実味のあるものとなります。そのため、このルールの制定の議論にこれほどの時間(既に約1年が経過しています)を割くのでしたらばarbcom成立に向けての議論に力を注いでいただきたいと思います。よろしくお願いいたします。--Suisui 2006年11月10日 (金) 03:39 (UTC)
手続はWikipedia:管理者の辞任における退任とその手続に準ずるということで問題ないでしょう。これから行われるテスト等で実際に管理者の解任がコミュニティの意思として確定した事例が現れてからでないと、「依頼はメタ・ウィキメディアのm:Requests for permissionsで行う。metaのルールにより、日本語版でsysopをしておりmetaでも活動履歴があるユーザーが申請を行う。」あるいは"A trusted person from that wiki should just provide a link here to the discussion and a very brief explanation of the reason for de-adminship and results of discussion"との規定以上のことを詳細にわたって決めるのは難しいのではないでしょうか。
ちなみに、日本語版で唯一のスチュワードのSuisuiさんの解任が合意されることは単純な確率論的計算では非常に可能性が低いとは思いますが、この場合は、コミュニティの意思決定があった事をウィキメディア、あるいはウィキペディア財団へ報告、付託する事になるのではないでしょうか。それ以上詳細は実際にその場面になってみないと、政治的に微妙な力関係の問題も含んでいるでしょうから、個々で論議するのは少々机上の空論の恐れがあるのではないかとも思います。
Arbitration committeeについてはAotakeさんによる翻訳が存在しているようですが、実質的な議論が(私が知る限りでは)ほとんどなされていないような気がします。こちらはこちらで、誰が率先して成立に向けての議論の旗を振るのか、その人がいつあらわれるのかという問題から始まって、実際に作動するまで何年かかるかも未知数だと思います。この解任規定はたしかに時間がかかりすぎている感はあるものの、つねにWikipediaに時間をたくさん割けるとは限らないユーザーによって行われている議論であることからそれをなじるのは適当ではありませんし、現時点で正式化までもう一押しのところだと私は感じていますし、その感覚は間違っていないように思います。更に何年もかかるとは思いません。--Pugnari 2006年11月10日 (金) 11:33 (UTC)修正--Pugnari 2006年11月10日 (金) 12:13 (UTC)
Pugnariさまのご意見に同意します。Suisuiさまから、スチュワードとしてのSuisuiさまは「日本語版コミュニティの管理者の辞任手続(解任も含む)には通常関与しない」という点をお知らせいただきましたこと、及び、metaにおける管理者退任の申請後の具体的な手続(これはメタの問題ですね)についてご教示いただきましたことにつきましてお礼申し上げます。このすぐ下に、Ks aka 98さまからSuisuiさまへのご質問があります。私からもSuisuiさまからのご回答をお待ちしています。--anonymous000 2006年11月10日 (金) 13:38 (UTC)・Micheyさまからの私の質問へのご回答を受けてコメントを修正--anonymous000 2006年11月11日 (土) 01:03 (UTC)


まず、Stewardsについては、2006年の選挙のRulesを見てもどこかの言語版の管理者であることは求められていないようです。なので、管理者解任された場合でもStewards権限は残るてことでいいんじゃないすか。

で、suisuiさん、meta/stewardsの事情の説明ありがとうございます。

arbcomがないプロジェクトにおいては、管理者の解任のためにはコミュニティの合意があることが前提となる。metaへの依頼によって、依頼者の活動履歴、議論や投票、投稿履歴を参照し、stewardsがdesysopする、ということでよろしいでしょうか。その他、何点か確認させていただけると助かります。

  • コミュニティの合意があれば解任の措置は可能であること
  • その場合、「コミュニティの合意」が不可欠の前提であること
  • 合意にも関わらず解任されないことがあること(合意形成における手続き不備を除く、解任されない事例での理由がわかればたすかります)
  • 「機械的に権限与奪を行うことはしません」、というご発言がありますが、これはStewards don't decideというポリシーを踏まえると、無条件にdesysopするわけではなく手間をかけて確認はするが、判断をするわけではない
  • 解任の申請時に日本語版で活動しているsuisuiさんがdesysopすることをリクエストする旨表明しておくことで(unless they request it themselves)労力は軽減されるのでしょうか。

また「arbcomを設立させれば逆にstewardsが機械的に近く処理できる」というご指摘は納得いくもので、考慮すべきものだと思いますが、arbcomの設立は必須ではなく、また制度化への困難は、この方針を上回るのではないかと思われます。もう一点確認させてください。

(お答えはこの直下に書いていただけるのがよいと思います)--Ks aka 98 2006年11月10日 (金) 12:35 (UTC)

私の質問の下にご回答をいただきました。ありがとうございます。その下等に私のコメントをしています。--anonymous000 2006年11月11日 (土) 04:07 (UTC)

(Ks aka 98 さまの上記のご質問に対するSuisuiさまのお答えを私からもお待ちしています。お答えはこの直上に書いていただけるのがよいと思います。また、私の下の質問に関しても、もし何か他にご存じであれば、お知らせ下さい。)--anonymous000 2006年11月10日 (金) 13:47 (UTC)割り込みを撤回しメッセージ追加--anonymous000 2006年11月11日 (土) 00:00 (UTC)


私からも質問です。

  • これまで辞任された管理者のうち、「自動退任」又は管理者自らが退任の申請をしなかった「自発的辞任」の場合に、メタへの管理者退任の申請は、日本語版ウィキペディアの誰が実際に行なってきたか。
  • 自発的辞任で自分から辞任申請しなかった管理者はどの程度いるか。
  • それによって、これまでに何らかの問題が生じたことがあったか。

の3点について、ご教示いただけますと幸いです。--anonymous000 2006年11月10日 (金) 13:38 (UTC)

Suisuiさんではありませんが、管理者辞任の処理が過去どのように行われてきたかについては、Wikipedia:管理者の辞任の履歴をたどっていくのがもっとも正確だと思います。Suisuiさんは日本語版の辞任にあまり関わっていませんし、他に把握している人がいる可能性も低いので。たとえば、私の辞任については、Tomosさんに開発者(当時はStewardがありませんでした)に対して申請していただきました[1]。--Michey 2006年11月10日 (金) 17:19 (UTC)

ありがとうございました。とりあえず、(主に)自動退任について、誰がm:Requests for permissions#Removal of accessにリクエストを出したか調べてみました。
  • Yoshitaka MiedaさんとOjigiriさんの自動退任→Kinoriさんが2004年11月24日 (水) 05:25 (UTC)に指摘→Tietewさんが2004年12月8日 (水) 10:33 (UTC)にリクエスト
  • MHさんの自動退任-2005年2月26日 (土) 18:44 (UTC)指摘→Tietewさんが2005年3月1日 (火) 09:04 (UTC)にリクエスト
  • (ついでに)Gさんの自発的退任-2005年2月9日 (水) 05:00 (UTC)表明→→Tietewさんが2005年2月14日 (月) 14:40 (UTC)に促し→Tietewさんが 2005年3月1日 (火) 09:04 (UTC)にリクエスト
  • Skylabさんの自動退任→Lusheetaさんが2005年10月8日 (土) 13:13 (UTC)指摘→Suisuiさんが2005年10月8日 (土) 23:41 (UTC)にリクエスト
  • Tekuneさんの自動退任-Seibuabinaさんが2006年3月9日 (木) 07:10 (UTC)指摘→→ Lusheetaさんの促し(2006年3月18日 (土) 02:53 (UTC))があり、すぐりさんが2006年3月24日 (金) 16:30 (UTC)に依頼。

従来、時に手続がやや遅延することもあったが、その場合も一般ユーザーからの「促し」があり、それに気づいた管理者が自発的に対応してきた、という風にまとめられそうです。私はひとまずこれでいいように思います。--anonymous000 2006年11月11日 (土) 00:00 (UTC)


>コミュニティの合意があれば解任の措置は可能であること
コミュニティの合意があったとしてもstewardsが普段活動している。ローカルのプロジェクトでの解任は通常しません。この通常以外にあてはまるのはいまのところsysop vandalに相当する場合のみです。何故こうなっているかというと、他のstewardsがそれが適切かどうかを判断するのが非常に難しいからです。わかりやすい例では各stewards と makesysop, desysopされるユーザー間の利害関係、人間関係を把握することは他人には簡単にはできません。自分に有利になるよう権限を行使しにくくするためのルールなのです。たとえばコミュニティがstewardsの中で私が解任することを合意した、といってもそれは他のstewardsや財団に対して説得力をまったく持ちません。
>「コミュニティの合意」が不可欠の前提であること
この点は一概に申し上げられません。なにをもって合意とするかはプロジェクトごとに異なるからです。不可欠ですが、何が不可欠かはコミュニティやプロジェクトの規模、活動頻度など、いろんな要素を元にこのプロジェクトであればこれで合意形成としてよいだろう、という判断を各stewardsが行います。
>合意にも関わらず解任されないことがあること(合意形成における手続き不備を除く、解任されない事例での理由がわかればたすかります)
stewardsも通常のユーザーと同じくボランティアであり、義務はありません。そのため、単に手が空いていない、という理由で解任されないことは多々あります。実際私がstewardsになる以前はずっとその状態でした。(私と同時に10人増え、botフラグの付与がbcratに移り、その状況はかなり改善されています)数ヶ月から数年のスパンでみれば手が空いていないという理由で解任されなかった礼はないと思います。また、総合的に判断して前述の合意形成が不十分であると判断する場合も間々あります。日本語版の場合はそもそも何の議論をしているかを理解できる人はstewardsのなかで少ないですから、投票の様子や投稿履歴からざっくりな判断をされることになります。もしくは私のところにききにきます。
Meta:Steward policies#Stewards don't decide, they carry out/execute
stewardsは内部的には権限与奪権の権利を持つユーザーですが、wikipediaの外の社会に対して法的責任の分散の意味を持ちます。上述のとおり、自分が活動していない言語版についての権限与奪しか持たない、の意味は自分が理解できる言語版での活動はほぼ行えないことを意味します。つまり実質的にプロジェクトの運営に介入することはできません。こうした、実際には何らかの手段をとることができるけれども管理運営は無理でコミュニティに任せる、という方式を取ることで、管理責任の所在を分散し、法的管理責任所在の分散を行うことができるのです。こういった考え方はアメリカの判例に基づくものなので、日本でどれほどの効力を持つかは不明です。いずれにしてもこれによってオープンに集まっているユーザー個人に責任がかぶらないようにしつつ、特定のプロジェクトが誰かの所有物にならないよう、できないようなルールとして設けられたのが現在のstewardsです。決定を下さない、と明記してある理由はそこにあります。考案仮定ではbcratに与奪両方の権限があるはずでしたし、MediaWikiは実際単独でインストールした場合bcratがリ単一プロジェクト内で両方の権限を持ちます。リンクしていただいた方針はユーザーに対しての説明でもありますが、社会に対して「決定は行わない」というルールになっているだろう、と示すためものでもあるのです。
>suisuiさんがdesysopすることをリクエストする旨表明しておくことで~労力は軽減されるでしょうか
現状asiaのtimezoneのstewardsも二人になってしまったため、ルール上は軽減されると考えることもできます。あらかじめ要求が出ることを知ることができますし、議論の内容や該当ユーザーの行動が(日本語が読めない方よりも)すばやく正確に把握できるからです。しかし私個人としては、現状のルールではリクエストされても拒否します。ただでさえ何がおきているのかわからない巨大プロジェクトですので、上述のプロジェクト私物化の観点から見ても法的責任の分散の観点からみても健全とは思えないからです。たとえば、タミル語が読める人がいないことを想定してこの例を出しますが、タミル語版からstewardsが出て、その後タミル語版から出てくる権限のリクエストがそのstewardsが行うよう集中していた場合私たちはどういった考えを持つでしょうか?
arbcom設立の議論はjaではまだなんらされていないように思います。しかし逆に、stewardsのルール上はarbcomがあるプロジェクトとないプロジェクトで分けて考えられています。たとえば権限与奪に関して一ユーザーの意見とarbcomの決定がある場合、stewardsはあきらかにarbcomの決定を優先します。
>「自発的辞任」の場合に、メタへの管理者退任の申請は、日本語版ウィキペディアの誰が実際に行なってきたか。
Tietewさんが多いと思います。metaでのpermission requestはよほど小さなプロジェクトでない限り、metaでの編集実績を加味して判断されるので、metaでmetaの活動をしていない方が申請をしても却下されることがあります。最近はstewardsの数が増えたため、簡単な認証でもとのプロジェクトでの活動を加味するように変化しつつある状態です。
>自発的辞任で自分から辞任申請しなかった管理者はどの程度いるか。
数えたことはありませんが、半分くらいだと思います。
>それによって、これまでに何らかの問題が生じたことがあったか。
ありません。というよりも、問題がおきそうだった場合Tomosさんや私が依頼を出したり、誰かstewardsやdeveloperに対処を直接お願いするなどして処理してきているため、現在のところも問題があったとしても多少時間がかかった、程度です。今後同様にできるかどうかはわかりません。;-) そういった意味でこの解任のルールをわざわざ設けてarbcomがない状況は非常に中途半端です。 --Suisui 2006年11月11日 (土) 02:24 (UTC)
私の質問についてのお答えを頂きありがとうございました。(留保付きながら)「これまでは問題ありません」ということで安心しました。Ks aka 98 さまのご質問に対するお答えは、一部かみ合っていないように思われました。特にArbComに関して、Wikipedia‐ノート:管理者の解任#ArbComと管理者の解任規定の関係 に私からコメントしております。なお、ArbComに関する以後の議論はWikipedia‐ノート:Arbitration_policyかWikipedia‐ノート:Arbitration_Committeeでお願いします。議論とは無関係なのであと少しだけ。財団の見解でも、スチュワードであるSuisuiさまが(共同して)ウィキペディア外部に対する法的責任を負っていることを自ら表明されたことに敬意を表します。なお、日本法の下での日本での日本語版ウィキペディアに関する法的責任は、原告(訴える人)及び日本の裁判所が決めることで、被告(訴えられる人)が決めることではありませんが、私の日本法の理解によれば、「少なくとも」Suisuiさんはその責任を免れることはできないと考えています。この場の議論の促進の妨げになるためこれに関する細かい説明は端折ります。この点に関して議論をすすめることはお控えいただきますよう(外部との関係に関する法律上の疑問点などは、ボランティアである利用者にではなく、専門家へのコンサルト等を)お願いします。--anonymous000 2006年11月11日 (土) 04:07 (UTC)・リンク修正2006年11月11日 (土) 09:01 (UTC)


[編集] 現状調査等のまとめ

節を分けました--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

さて、「コミュニティの合意を前提として解任の措置は可能であるが、stewardsの負担が大きい」ということであれば、ローカルで対応できる方策を検討する必要があるのかもしれません。以下は思い付きで。

  • 自発的な辞任を促すことで解任措置に替えることは、ひとつの対処となるでしょう。特に「解任」「自発的な辞任」を区別することが求められないならば、手続き上は過去の自発的な辞任と同様ですから、stewardsの負担も特に大きなものとはならないと思われます。「コミュニティの要望で管理者権限を返上する。」「他の参加者が、以下のような理由で、管理者に辞任してもらうことを望む」といった記述からは、最初からこれでいいのかとも思います。解任決定後1週間程度の期限を決めて、この間に自発的に辞任しない場合は、次のステップへ。
  • この段階でmetaへ、ということが妥当かと思います。管理者であればstewardsの負担を考慮して、このような事態は起こらないと思われますが、個人的な信条などによってやむをえずstewardsへ、と。この場合、実際に解任されるまでの期間は、権限行使が可能なのかどうかは決めておく必要があるかもしれません。
  • 解任されるまでの期間の権限行使が禁止された場合、なお権限を行使し続けた場合や、解任された管理者が暴走する可能性はゼロではありません。この場合、ローカルで取りうる対処としては、コミュニティの合意に反した行動としてブロックするということが考えられます。
    • ブロックによって、通常のユーザとしての作業も不可能となりますが、それは認められるのか
    • ブロックの方針には「コミュニティの合意に反した行動によるブロック」は明文化されていない
  • stewardsの判断の結果、解任しないという場合を検討する必要があるかどうかについては、上記確認の回答を待ってから考えるということで。--Ks aka 98 2006年11月10日 (金) 12:35 (UTC)
1点目については良さそうに思います。ただ、従来自分で申請した・しなかった実績がどの程度あるかが、問題となるかも知れません。3点目(管理者権限喪失までの荒らし化)は、私の理解では、ブロックしても自分でブロック解除ができるので、「緊急解任」が必要となる場面なのかも知れません。4点目(stewardsの判断で解任しないという場合)というのは、ローカルで決める範囲を超える(メタの領域)のように思います。取り急ぎ考えたところをお伝えします。--anonymous000 2006年11月10日 (金) 13:47 (UTC)
>自発的な辞任を促すことで解任措置に替えることは、ひとつの対処となるでしょう。特に「解任」「自発的な辞任」を区別することが求められない
区別は求められませんが、本人からの依頼の場合多くはその場で対処されます。ただし本人からの依頼とはmetaで本人が申請を行った場合のみです。それにもいくつか条件があります。(metaでまったく活動がない場合などは割と長期化します。)そのためこれまでと同様では困ります。
>sysop vandal
この場合私が対処することもできますが、細かいコメントは避けます。ルール上は可能ですが、個人の判断で行うことは望んでいません。これまでの例では#wikimediaなどでリアルタイムで監視した上で複数のstewsrdsで実際見て決めます。また、たとえば解任をjaで決定されたsysopが解任までに行った行動が通常の削除依頼の処理だったとしたばあい、心理的には荒らしと思う方は多いでしょうが、それを荒らしと扱うことはありません。さらに、私ができるといっても私は皆さんと同様に24時間365日暇なわけではありませんし一日中PCの前にいるわけでもありません。いたとしても全ての時間をwikimediaに費やしているわけでもありません。他のstewardsも同様です。その点ご考慮くださると助かります。それらとjaの規模を踏まえたうえでarbcomの設立が適切と判断したということを一応申し上げておきます。--Suisui 2006年11月11日 (土) 02:24 (UTC)
コメントありがとうございます。ひとまず「緊急解任」という万が一の事態に対処いただける場合があることをお知らせいただき、安心いたしました。Arbcomに関してはWikipedia‐ノート:管理者の解任#ArbComと管理者の解任規定の関係にコメントしていますが、この点は以後Wikipedia‐ノート:Arbitration_policyかWikipedia‐ノート:Arbitration_Committeeでご議論下さい。--anonymous000 2006年11月11日 (土) 04:07 (UTC)・リンク修正2006年11月11日 (土) 09:01 (UTC)

Suisuiさん初めまして。そしてご説明ありがとうございます。他にもももっと書きたいことがあるのですが、今終わらせなくてはならない仕事をかかえているので、自発的な辞任についてひとつだけ。

>>自発的な辞任を促すことで解任措置に替えることは、ひとつの対処となるでしょう。特に「解任」「自発的な辞任」を区別することが求められない
>区別は求められませんが、本人からの依頼の場合多くはその場で対処されます。ただし本人からの依頼とはmetaで本人が申請を行った場合のみです。それにもいくつか条件があります。(metaでまったく活動がない場合などは割と長期化します。)そのためこれまでと同様では困ります。【上記のSuisuiさんによるお書き込み】

メタもどんどん変わっていっているので、あまり昔の事例は知識として知っているといいかも知れませんが、現在協議している事項にはあまり役に立たないと思いますので、最近の例を取ってみると、

  • Sampoさんがメタで自発的な辞任依頼をした時、解任のためにメタでのアカウントを取られたようで、それ以前のメタでの履歴が全くありませんでしたが、2006年9月6日に依頼をされて、手続きが終わったのは2006年9月7日でした。
  • FeZenさんがメタで自発的な解任依頼をした時も、解任のためにメタでのアカウントを取られたようで、それ以前のメタでの履歴が全くありませんでしたが、2006年10月1日に依頼をされて、手続きが終わったのは2006年10月5日でした。
  • Lusheetaさんがメタで自発的な解任依頼をした時は、メタでの活動履歴があったにもかかわらず、2005年11月26日に依頼をされて、依頼が承諾されたのは2005年12月23日でした。もっともこの時はシステム上のバグがあり、システム上でも手続きが終わったののは2006年1月13日というおまけが付きました。

これらは、Suisuiさんの“metaでまったく活動がない場合などは割と長期化します”という説明と相反します。Suisuiさんは他のスチュワードと違う基準を使用されていると言うことでしょうか?ちなみに手続きが直ちに終わった方はスチュワードの問い合わせEメールにすぐ返信したり、依頼後に出されたスチュワードの指示に従い参加しているローカル版の利用者ページで遅滞なく英語で辞任の意思表示をしたからで、確かにその依頼が本人によるものだと確認さえできれば(つまり他人による虚偽の書き込みではない)、自発的な辞任についてはメタでの履歴はあまり影響がないように見受けられます。--Californiacondor 2006年11月11日 (土) 06:22 (UTC) 【誤字脱字などを修正及び移動が終わったため移動承諾削除--Californiacondor 2006年11月14日 (火) 00:01 (UTC)】

m:Requests for permissionsでは、1ヶ月で500件近くの膨大な履歴を抱えながらそれなりに処理されているようだけどな、と素朴な疑問を持っていたのですが、Californiacondorさまから具体例を挙げていただき安心材料が増えました。調査結果をお知らせいただきましたこと、また、ローカルからmetaへの依頼方法等に関する議論の移動へのご承諾に関してましても、深くお礼申し上げます。--Anonymous000 2006年11月11日 (土) 09:01 (UTC)


Suisuiさんお答えありがとうございます。

えー、とりあえず、解任の手続きに則ることで日本語版では合意が形成されたとみなし、これをもとに対象となる管理者が自らmetaで辞任の申し入れをするという形なら辞任は受け入れられるということでよさげです。そうではなく、解任の決定を元に対象となる管理者以外の人がmetaにリクエストした場合、suisuiさん以外のスチュワードの方の手を煩わせ、合意形成の確認や「suisuiさんへの問い合わせ」などを経て、「投票の様子や投稿履歴からざっくりな判断」されるかもしれないし、「単に手が空いていない、という理由で解任されないこと」もあるかもしれないが、現在の解任のシステムがmetaのdesysopのシステムと合致していないわけでもない。スチュワードとしては、arbcomの決定があるほうが判断が容易であり、好ましい。…てなところでしょうか。

ということなら、「管理者の解任」の立ち上げを継続して進め、metaで時間がかかってしまう場合の対処策を(必要ならば解任のノートで)検討し、arbcomについては別途検討をはじめる、ということでよいのではないかと。--Ks aka 98 2006年11月12日 (日) 06:43 (UTC)

Ks aka 98さま、おまとめいただきありがとうございます。ついでにもう1点、「この方針(「Wikipedia:管理者の解任」引用者注)ができたとしてもarbcomができるまでの一時的なルールにしかならず」というSuisuiさんのご意見、すなわち、「日本語版ローカルにArbComができた場合には、『管理者の解任』規定が当然に無効となる」というご意見に関して、コミュニティでの合意はない(コンセンサスどころか、Suisuiさんのご意見への賛同は、今回の議論の中でここまで全くない)ことについても確認しておきます。--Anonymous000 2006年11月12日 (日) 12:01 (UTC)

この件に関しては、Wikipedia‐ノート:管理者の解任#ArbComと管理者の解任規定の関係(リンク切れの際の差分に確認事項があります。--Anonymous000 2006年11月19日 (日) 06:08 (UTC)


[編集] 改めて本題

節を分けました--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

Toki-hoです。suisuiさんおこたえありがとうございます。Californiacondorさん、ご調査ありがとうございます。みなさまの真摯な議論に感謝いたします。さて、拝読したかぎりにおいて、当該管理者本人がメタにアカウントをつくって辞任も申し出る(いままでの自発的辞任と同じ)場合は、うけいれられる。またいままで活動がなくなった管理者に対しておこなっていたように、メタにおいて信頼のある利用者が申請した場合にはうけいれられる。ということでよろしいでしょうか。で、問題になっている「管理者の解任」が成立した場合、管理者本人がそれをうけいれて自ら辞任する場合は有効にはたらくでしょうし、そうでない場合もメタに信用のおけるユーザーがいってかくかくの管理者はコミュニティーの合意によって解任相当とされたという場合でしたらうけいれられる、と理解しました。ただそのほかの場合、メタに信用されているユーザーがだれも申し述べに行かなかった場合はどうなるのでしょうか。そうなった場合は「だれか」がメタにいって申し述べるのだと思うのですが、そのだれかのいうことが信用されるかどうかということが私には心配でなりません。そのあたりはみなさまどうお思いですか?せっかく、ローカルで「解任」の規定をつくってみんながこれであの管理者は解任されると思っても、メタでうけいれられないようなら、事情を知らないひとには、この解任規定が虚偽のようにうけとられ、ひいてはコミュニティーに対する不信をよぶのではないでしょうか。その点、心配でたまりません。発足前にそのあたりのメタへの「根回し」をきちんとしておくべきだというのは上記の理由です。たいへん執拗にみえるかもしれませんが、「管理者の解任」が十全なものになるようにという意見ですので、いまいちどご意見をおよせくださいませ。Toki-ho 2006年11月13日 (月) 00:48 (UTC)
まず第一には、今までに meta へ desysop 依頼の実績のある方に個別にお願いするという方法がとれるでしょう。問題は、これらの方たちが、理由はいかにせよ、拒否または黙殺された場合ですよね(故意に拒否または黙殺されるとなるとコミュニティ全体と対立する行為であると思いますが)。この場合、「だれか」がどの程度信頼されるかは私にはわかりませんが、日本語を使わないスチュワードの方等への負担減を考慮して、次のような方策も一案であるかと。
  1. Wikipedia:管理者の解任の最終節に英語によるサマリーを設ける。動議提出権者の資格、過半数可決等。
  2. (賛成 support)(反対 oppose)といった投票形式をとる。投票終了後、動議提出者および動議賛同者のいずれかが、投票結果の英文サマリーを記す。
    This request to dismiss User:xxx from sysop is approved by xx supports and xx opposes... etc... とかなるんですかね(英作文苦手なので)。英語の得意な方にあらかじめテンプレートを用意してもらうといいのかもしれません。
  3. 動議提出者および動議賛同者のいずれかが meta に m:requests_for_permissons 経由で報告。この際、英語の達者なユーザーにお願いして照会先を引き受けてもらうことも考えると良いのかもしれません。
文字化けの問題とかもあるので、これがどのぐらい現実的かはよくわかりませんけれども。日本語の部分が化けると同時に1バイト文字の部分も化けてしまうんでしたっけ?--Pugnari 2006年11月13日 (月) 06:39 (UTC)

m:requests_for_permissonsのdesysop依頼をみると、たいしたことは書かれてなくて、投票がローカルで信任を得ているかどうかがまずはポイントのようです。なので、公式化されてて、できればルールの概要の英文サマリーをつけて、賛否がわかりやすくなっていればよさそうな。方針化(あるいはその前の段階で)、バベルかreportあたりで報告/説明するとかがいいのかなと思いました。こっちのもちょと書いた。Wikipedia‐ノート:Arbitration_Committee--Ks aka 98 2006年11月13日 (月) 06:59 (UTC)・リンク先修正--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

Toki-hoさま、事前に直接のご承諾をいただくこともなく移動したことをお詫びいたしますとともに、引き続き議論にご参加いただけますことをお礼申し上げます。また、本題に戻していただき(^_^;;ありがとうございます。Toki-hoさまやCaliforniacondorさまをはじめとする皆様との議論に参加していて、私自身も、Wikipedia:管理者の辞任#退任とその手続きの中に辞任すべき理由の2番(「他の参加者(=コミュニティ)が、...管理者に辞任してもらうことを望む」こと)を決定した後の具体的手続まで、ある程度明文化しておいた方が良い気がしてきたので、引き続き議論に参加させてください。
まず、基本的なところから確認です。Toki-hoさまが上の方で述べられている「管理者の解任」をコミュニティで決める手続(つまりWikipedia:管理者の解任の手続)については、少し誤解があるようですので、ここで簡単にですが説明いたします(Wikipedia:管理者の解任/FAQも昨日加筆していますのでよろしければ合わせてご参照下さい)。私も議論の途中まで誤解していたのですが(Wikipedia‐ノート:管理者の解任#投票所の設置時期と動議提出のページを参照)、解任の動議(正確にはコミュニティによる投票を求める意思の表明)はコメント依頼ではなくWikipedia:管理者の解任#管理者の解任で行なわれます。そこで5票以上の有効な動議への賛同票が集まると、はじめて「投票ページ」が作成され、その48時間後から1週間のコミュニティによる投票に移行するという2段階方式となっています。コメント依頼での議論は、動議提出・動議への賛同及び動議が成立した場合の投票行動を決定するための材料となるに過ぎないともいえます(もっとも、ここで説明拒否などがあれば、そのような行動も含めて管理者としての資質や適性をコミュニティが判断することは、当然あり得ることです)。つまり、管理者の解任に関するコミュニティでのコンセンサス(全員一致又は圧倒的多数による合意)の内容は、「当該管理者に管理者でいてほしいというコミュニティの『コンセンサス』がないことを過半数による投票で決める手続」、という理解が正しいように思います。--Anonymous000 2006年11月13日 (月) 08:50 (UTC)
この続きに、実際の手続について検討した文面(相変わらず長文)を用意していたのですが、ちょうどKs aka 98さま、Pugnariさまと編集競合したので(コメントありがとうございます)、ちょっとまとめなおして後で投稿します。誰がメタにリクエストするか、ということと、いかに容易に日本語版コミュニティの意思決定の内容をメタの(非日本語話者の)スチュワードに確認いただくか、というところの検討になるのだろうと思います。取りあえず思ったところでは、「管理者の解任」の文言、「管理者の解任における動議」や「投票ページでの投票結果」の工夫等に加えて、Template:最近のウィキペディア(ポータル)では英語も含めて投票結果を告示するとよいかもしれないかな、と考えました。--Anonymous000 2006年11月13日 (月) 08:50 (UTC)

Wikipedia‐ノート:管理者の解任の整理が一段落したので戻ってきました。ここと関連する話題(ローカルでの処理)として、「投票結果の最終確認作業」と「ポータル等」への告知について、Wikipedia‐ノート:管理者の解任#解任投票終了後のメタへのリクエストの前のローカルでの手続という新しい提案(文案付き)を行なっています。やっつけ仕事で作った文案なので、語句の統一なども不十分だと思うため、お気づきの点などがあればご指摘いただけると幸いです。議論の場が分散することになり、皆様にはご不便をおかけしますが、よろしくお願いします。

解任投票の結果をローカルで確認・告知した後の段階(つまり「誰がメタにリクエストするか」)、「日本語版ローカルでの意思決定をいかに日本語話者ではないメタのスチュワートにうまく伝えるか」とが、残された議題になるのだろうと私は認識しています。ひとまず、前者に関してはPugnariさま提案の3番ですね。後者は「管理者の解任」での話題のようにも思うのですが、英文サマリー。。う〜ん。。日本(語)POV(^_^;;な私にはちょっと荷が重いかも。。誰かお得意な方はいらっしゃらないかな〜と、コミュニティに下駄を預けてみることにします。投票ページを2カ国語にするというのは、比較的やりやすいのかも知れませんね。私はAphaiaさんなど、メタでも顔が広そうな方を通じた「口利き」をお願いするのもよいかな、と思っているところですが、いかがでしょうか?(管理者の解任の方でも英語版での状況等のご意見など頂いておりますので)。--Anonymous000 2006年11月13日 (月) 16:16 (UTC)・節分けのための署名付記


[編集] 誰がメタにリクエストするか

節を分けました。--Anonymous000 2006年11月14日 (火) 01:17 (UTC)

で、私でもできることとして、誰からリクエストできるかについて、少し皆様のご意見を整理してみます(敬称略です。ご了承下さい)。私が先ほど予告していた長文投稿の「一部」(^_^;;になります。(当初、Wikipedia:管理者の辞任#自動退任についての手続を「管理者の解任」向けにアレンジする作業のための文案を用意していました。これはその4番の検討です)--Anonymous000 2006年11月13日 (月) 16:16 (UTC)

  • (Ks aka 98案)--2006年11月14日 (火) 01:17 (UTC)追加
  1. 管理者の自発的な辞任を「推奨」(解任決定後1週間程度の期限)
  2. (それがされない場合)metaへのステップへ
  • (Pugnari案)
動議提出者および動議賛同者のいずれか(「英語の達者なユーザーにお願いして照会先を引き受けてもらう」?)
  • (Californiacondor案〜自動退任に関して)
現行の管理者(sysop)を「日本語版で信頼されているログイン・ユーザーで、メタ・ウィキメディアでもアカウントがあるユーザー」まで広げる。
  • (Anonnymous000案)
  1. 当該管理者」が自発的にリクエストを推奨
  2. (それがされない場合)48時間以上経過した後ユーザーからの「促し」があり、さらに48時間経過した場合、「別の管理者」(メタにアカウントをもつ者。以下同じ)
  3. (それもされない場合)同様の促しと期限経過後「動議提出・賛同者
  4. (それもされない場合)同様の促しと期限経過後「投票に参加したユーザー
  5. (それもされない場合)同様の促しと期限経過後「動議・投票に参加していない動議提出権者・投票権者
くらいに細分化。期限の「48時間」は例示だが、「促し」(促しとは、動議ページ=Wikipedia:管理者の解任#管理者の解任でユーザー(誰でも良い)からメタでのリクエストをして報告するよう促すこと)を含めると最低でも各段階で96時間確保できるので、比較的妥当な線と思われる。デメリットは複雑になることだが、できるだけはじめの方の段階での対応が望まれるので(決定すれば、Wikipedia:管理者の解任/FAQにも明示します)、少なくとも4段階目以降は少し考えすぎの感も(考え過ぎとすれば、Pugnari案に近い。1+3のみとするとほぼコンセンサス?)。3,4で動議提出・賛同または投票した者だけにリクエストできる者を限定しているのは、メタからの「信頼できるユーザーか」の確認をしやすくするため。
私の案についてですが、極めて複雑なのですが、責任の所在を明確化するとともに、メタにできるだけ無用な混乱を招かないことを念頭に置いています。これに対して、「Californiacondor案」は「信頼されているログイン・ユーザー」の基準が不明確で、もう少し明確化なり限定なりする必要があると思います。Pugnari案は、非常にシンプルで分かりやすいため、「これで行く」ということであれば一つの選択肢になりうると思います。以上取り急ぎ。--Anonymous000 2006年11月13日 (月) 16:16 (UTC)
#現状調査でのまとめでいただいていたKs aka 98さまからのご意見(2006年11月10日 (金) 12:35 (UTC)の差分)が落ちていましたので追加しています。大変失礼しました。--Anonymous000 2006年11月14日 (火) 01:17 (UTC)

m:Requests for permissionsでの作業ですが、トラブルが起きたときの対応を念頭にしたほうがよいと思います。例えば、de-adminshipの申請があったときに、metaでの活動実績のあるユーザーが「今回の投票でソックパペットが投票を操作したので無効である」と主張すれば、Stewardはde-adminshipの前に調査することになるでしょう。Stewardは申請者へも問い合わせをするでしょうから、その際に適切に対処できる人が望ましいでしょう。--Michey 2006年11月13日 (月) 18:54 (UTC)

あのう、(Anonnymous000案)ですが、正直言って「そこまでする?」という気がします。すみません、大変失礼な書き方で。こういった時は理由や理屈を述べるべきなんでしょうが、拝読させていただいた時の私の第一反応がそうだったもので・・・(目と頭が拒否反応起こしました(@_@)、それが理由といえば理由かも)--Californiacondor 2006年11月14日 (火) 00:01 (UTC)
率直なご感想ありがとうございます(^_^;;。そうなんです。「手続規定」の一番のミソ(大事なところ)でもあり、大変なところでもあるところは、「決まり」を守らないとどうなるかということを詰めていく作業なのです(例えばWikipedia‐ノート:管理者の解任#無効票の扱いがいい例です)。私が当初は「棚上げ」を繰り返しすすめていたのも、あまりに例外的なところを決め始めると、文字通りきりがない作業となることを予測していたためです。Tanuki_Zさんがしきりに「面倒なので」とコメントされていたのも、恐らく同じような感覚をお持ちであるためだろうと思っています。しかし、皆様のご意見、特にmetaのスチュワードへの円滑なリクエストができるようにする必要性のご指摘もありますし、日本語版ウィキペディアとして「メタになるべく迷惑をかけない」(メタにローカルの議論を持ち込まない)という必要性はやはり重要だと今では考えています。また、せっかくここまで議論がすすんできていますので、私としてはもう少し話をすすめたいと思います。--Anonymous000 2006年11月14日 (火) 01:17 (UTC)
さて、Micheyさまのご指摘もありますのでちょっと話を整理したいと思うのですが、ローカルでの意思決定が「完全に確定」(ソックパペットによる不正投票などの疑義があった場合等には、CUなどの処理が全て完了して、投票結果による意思決定がひっくり返らない状態)となった後に、はじめてメタへのリクエスト手続きをすることができるようにしておく必要があります。ローカルでの意思決定を「完全に確定」させる作業は、Wikipedia‐ノート:管理者の解任#解任投票終了後のメタへのリクエストの前のローカルでの手続で行なっています。この中に、例えば「異議申立可能期間」(これは、当該管理者がローカルのコミュニティでの意思決定を受入れて自発的に辞任を行なうなり、当該管理者を含むコミュニティ(動議提出権者や投票権者)からの異議申立て(例えばCU依頼)を行なうことができる期間。Ks aka 98案の「1週間程度」の期間に相当)を定めておくことで解決できます。当該管理者が自発的に辞任しない場合、異議申立期間を経過し、かつ、異議が出た場合のその処理の完了した後で、ローカル所定のユーザー(これは例えばPugnari案としてもよいでしょうし、Anonnymous000案の2+3あたりにしてもよいのかもしれません。)から、メタへのリクエストを可能にするというような手続を作っておくことで、ローカルの意思決定の点で疑義が出る余地はなくなる(それを許さないという制度にする)ことが可能になります。ということで、私としてはローカルでの意思決定を「完全に確定」する規定については、Wikipedia‐ノート:管理者の解任#解任投票終了後のメタへのリクエストの前のローカルでの手続で行ないたいと思います。あっちこっち行き来させてすいませんが、引き続きご意見をお寄せいただけますと幸いです(>皆様)。--Anonymous000 2006年11月14日 (火) 01:17 (UTC)

Wikipedia‐ノート:管理者の解任#解任投票終了後のメタへのリクエストの前のローカルでの手続の文案に、「異議申立期間」を組み込んで修正しています。自発的辞任が行なわれず、かつ(最低1週間の)異議申立期間が終了した後のに投票結果の「最終確認」がされた後に、当該管理者以外の第三者がメタにリクエストする、ということになるかと思います。--Anonymous000 2006年11月14日 (火) 02:53 (UTC)

上記の文案が自分で読んでも目が回りそう(^_^;;なくらい分かりにくかったので、再度修正しました。これでも目が回るかも知れませんが(>Californiacondorさま、すいません)、「異議申立期間」に関する部分は「異議申立ての方法と手続」として別に分けました。この部分は公式化の前には棚上げにしておく(いざというときの「備え」として草案状態で置いておく)くらいがいいかな、と思っています。「投票フェイズ終了後の処理」として残した1から4がこちらの手続とも本来関係する部分です。「誰がメタに報告するか」も含めて、ぜひみなさまのご意見をお待ちしております。--Anonymous000 2006年11月14日 (火) 15:59 (UTC)
「最終確定」までの間に1週間の「異議申立期間」=「自発的リクエスト推奨期間」を置いていますので、先にAnonymous000案として提案した細かい時間制限で分ける案は撤回します。また余談ですが、「最終確定」後も管理者が自らリクエストを出すことは当然許容されます。)--Anonymous000 2006年11月16日 (木) 16:42 (UTC)・メンテナンスに伴い移動--Anonymous000 2006年11月19日 (日) 06:08 (UTC)

[編集] はじめてお越しの方は、ここからどうぞ

井戸端への再告知にあたり、節を切りました。全体的にインデントや要約などを修正。内容は現時点に併せています。--Anonymous000 2006年11月19日 (日) 06:08 (UTC)

[編集] 議論の整理

2006年11月19日 (日) 06:08 (UTC)現在

順調に「管理者の解任」の公式化に向けた「(正式)投票対象草案」の確定作業がすすんでいます。ローカルの意思決定(投票結果の「最終確定」まで)については、(解任)投票の結果の告示(報告)のタイミングや場所なども含めてほぼ形になりつつあります(Wikipedia‐ノート:管理者の解任#「投票フェイズ終了後の処理」文案)。議論の途中ですが、現時点での議論に基づいてWikipedia:管理者の解任/FAQ#投票結果の確認作業はどのように行うのですか?以降の部分を加筆していますので、よろしければご覧下さい。あとは、投票結果の確定と、異議の申立てに関するローカルでの処理について、詰めの作業を行っています。管理者を解任するかどうかについてのローカルの意思の確定について、これまでの議論の結果を要約すると、

  1. 1週間の投票期間が終了。
  2. (動議提出権者が)「確認」。
  3. 1週間の「異議申立期間」が経過すると、投票結果が確定。
    1. 異議申立ては特殊なケース以外推奨せず(FAQ参照)、「異議申立ての規程」は公式化パッケージに含めず草案のままあえて残す?。
    2. 異議申立期間を、単純な無効票のチェック漏れなどにも使えるようにする?。この場合は、「異議申立ての規程」を草案のままにはせず、公式化パッケージに含めた方がよいのでは?(私見)
    のどちらが良いか、Wikipedia‐ノート:管理者の解任#異議申立制度(投票結果の確定の関係で)で意見募集中。
  4. 投票結果の確定後、Template:最近のウィキペディア(ポータル)に投票結果の確定を告示(報告)。投票結果の確定後は、一切の異議申立て等を不可とする。
  5. (誰かが)meta(m:Requests for permissions)へリクエスト→ここで募集中の意見
という手続にする方向で提案中です。1〜3(および4)によって、ローカルの意思決定はかなりがっちりとできるのではないかと思います。
  • ここで募集中のご意見−「管理者の解任」に基づく投票によって、ローカルの意思が「解任」することに確実に決定した後に関する議論(上記の5の段階)。メタ(ウィキペディア全体)での解任手続の依頼(リクエスト)をいつ誰がどのように行うか
    • 「いつ」は上記の4まで行ってローカルの手続が完全に確定して告示された後、「どこで」はm:Requests for permissionsへになります。
  1. 当該管理者が自発的にm:Requests for permissions(メタ)のm:スチュワードにリクエストを行う(自発的辞任)のが、メタにとってもローカルにとっても一番望ましいということ点はコンセンサスです。ただ、メタへのリクエストは英文で行う必要があります。
  2. 「英語の苦手」な管理者であっても、容易にリクエストできるようにする手助けとして、個人的なものとしてではありますが、Californiacondorさんから、「英語での自主的辞任の手続き方法」(以下「手引き」と略す)を作成するご意向を示していただいています。これが早期に完成すると、解任の際にも「自発的にリクエストしない管理者」は相当減ることが期待されています。ただ、「手引き」は今の時点ではないことや、「手引き」があっても自発的にリクエストしない管理者を想定する必要があるかどうかを考えておく必要があります。私見としては「解任された」管理者自身の心情を考えると、これをしない管理者が出ることは止むを得ないと考えています。
  3. スチュワード(メタ)の中で唯一日本語版ウィキペディア(ローカル)の管理者でもあるSuisuiさんからのコメントは、概ね次の通り整理できます((上の節「#辞任が決定した後のスチュワードへの依頼方法の具体化」を参照))。「当該管理者が自発的にリクエストしない場合でも、ウィキペディアの運営上、スチュワードが「自己の属するコミュニティの決定についてのメタでの手続」に関与することは好ましくないと考えられている。このため、解任が決まった後、自分からメタへのリクエストしない管理者について、Suisuiさん自身がスチュワードとして解任の手続きをとることは、原則としてはできない。」。したがって、これを前提に考える必要があります。
  4. (参考として)自動退任の場合には、別の管理者がメタにリクエストできることに、現時点ではなっています(この点は、Californiacondorさんの問題意識ですが、ここでは投票で「解任」が決まった後に、自発的に解任のリクエストをしない管理者に限定して考えています。)。

以上を前提として、管理者がコミュニティの決定によって辞任すべき場合に、自発的に辞任手続を取らないときにメタにリクエストを行う「リクエスト権者」を規定しておくか、あえて規定しないか、について、ここで現在議論を進めています。

いくつかの選択肢を用意してみました。どれが良さそうか次の#誰がリクエストするかについての選択肢で是非ご意見をお寄せ下さい。全体に要約を整理--Anonymous000 2006年11月19日 (日) 06:08 (UTC)

[編集] 誰がリクエストするかについての選択肢

案を整理し、節を切りました--Anonymous000 2006年11月16日 (木) 16:42 (UTC)

投票結果の最終確定後に、当該管理者が自発的にメタにリクエストしていない場合、メタにアカウントを持つ誰がm:Requests for permissionsに辞任の手続を依頼できると規定するか。ご意見をお寄せ下さい。(他に選択肢を加えていただいてもかまいません。)--Anonymous000 2006年11月16日 (木) 16:42 (UTC)・5の「それは」を明確化。--Anonymous000 2006年11月18日 (土) 06:21 (UTC)

  1. 動議提出権者(動議提出権者である管理者も含む)
    広めになる。しかし当該投票に参加していない「動議提出権者」がリクエストした場合に、メタでそれが正当な「リクエスト権者」による「正当な手続」に基づくものか、確認困難な場合が生じる可能性がいくらか懸念される。
  2. 当該投票フェイズの前の動議フェイズで、動議を提出またはそれに賛同した者
    コミュニティによる管理者チェックという側面を重視するとともに、メタでの確認を容易にするために絞る。
  3. 2の動議提出・賛同者、及び管理者
    管理者を含めて広めにする
  4. 管理者
    自動退任にそろえる。「信頼されたユーザー」(a trusted person) にもっとも近い
  5. あえて規定しない(棚上げ)
    特に「Californiacondor手引き」があれば、善意に期待というのも一つの選択肢。ただしそれでも管理者の自発的な手続がなされないと、結局誰かが「尻をぬぐう」必要が生じてしまう。

[編集] コメント

節を分けました--Anonymous000 2006年11月19日 (日) 11:43 (UTC)

  • (3に賛成)もし決めるのであれば、Tanuki_Zさんと理由は違いますが、決めておく必要があると考えます。なぜなら、解任された管理者の心情を考えると、自発的に解任依頼を出さない管理者が出ることは止むを得ない(想定せざるを得ない)からです。そして、そのような管理者が出たときに誰がリクエストするか決まっていなければ、コミュニティが揉めるであろうことは容易に予想されるので、「混乱の芽」を予めつんでおく必要があります。そして、上記の中では、私は3がよいと思います。従来の自動退任規程の踏襲に加えて、コミュニティのチェックという要素を取り入れた点で、バランスが良いと思うからです。もっとも、決めることができれば、1〜4はどれでもいいと私は思っています。--Anonymous000 2006年11月16日 (木) 16:42 (UTC)・意見を修正--Anonymous000 2006年11月19日 (日) 06:08 (UTC)
  • (5には反対-決めておくべき)Tanuki_Zさんとの私信でいただいたTanuki_Zさんのご意見です。--Anonymous000 2006年11月18日 (土) 06:21 (UTC)により記載書いていただきありがたいですが意見は真逆です。解任規定を「辞任勧告」しかできないものにすることには反対であるものの、具体的にメタに依頼する人間の条件をどうするかについては特にアイデアは無いというのが私の意見です。私は「あえて規定しない」=「管理者の辞任だけが頼み」とは別に考えていませんので、結果的に一番近い意見は実は5になります。もっと言えば下のKs aka 98さんの「原則として誰でもいい」という言葉になりますが。ただ基本的には意見なしと扱っていただければ。tanuki_Z(sysopは偉くない) 2006年11月20日 (月) 04:56 (UTC)
ご自身でコメントいただきありがとうございました。修正のお手間を取らせてすいませんでした。--Anonymous000 2006年11月20日 (月) 13:30 (UTC)
  • (4に賛成)理由は「自動退任にそろえる」ではなく、新任時に名前がメタに渡っているであろうと推測できるから。m:Requests for permissions#Removal of access には a trusted person とあり、もっとも近いと考えます。メタへの報告時点でコミュニティは疲弊しているはず、 de-adminship をもって手続完了と見るならば、ローカルとしては早くスムースに案件終了させる方法を選んでおくべきではないでしょうか。--やすとし 2006年11月19日 (日) 07:36 (UTC)
  • (3かな)3の人が推奨だけど誰でもいいと思う。手続だけの話なので、投票には関わっていなくてもメタに連絡するだけならやるよって人がいてもいいと思うのです(動議提出者とかよりも、そのほうが中立的って気もするし)。--Ks aka 98 2006年11月19日 (日) 07:40 (UTC)
  • (コメント)みなさま、ご意見ありがとうございます。告知の効果を実感しています(^^)。5の「決めなくても良い」というご意見は、「これを決めるために議論が遅延するのであれば」という留保付きであったと思うのと、皆様からのご意見を拝見していて、 本来「a trusted person」 である方を「ローカルに定めた規程によって、あえてできないと決める必要はない」ということも、大方一致しているのだろう、と私なりに整理できました。「自分で手を付けたことはケリがつくまで自分で責任をもって行ってもらう」という観点と、「なるべく多くの方の意見を取り入れてコンセンサスを目指す」という観点に従って、次の節に私案を提示してみます。いかがでしょうか?(想定される質問 (1)「合理的期間とは?」→常識で考えましょう(^_^;;。(2) 本人確認は?→私のユーザーページにヒントを作ってみました。署名先のリンクをどうぞ。外部サイトの設置者(著作権者)自身によるウィキペディアへの投稿と似たやり方です。--Anonymous000 2006年11月19日 (日) 10:48 (UTC)
  • (コメント)手順をいちいち示すよりも、「原則として誰でもできるが、以下が好ましい。」でいいと思う。まさかこの期に及んで自発的に動かない管理者もいないだろうし、そんな状況でじゃあメタに行くって言う人がいないってこともないだろうし、かなり最悪な事態なわけで。本人確認とかもこだわらなくてよくて、必要なら後で。ここは細部の詰めをするよりも、まとめて形にするの優先でいいんじゃないかなー、と。--Ks aka 98 2006年11月19日 (日) 11:02 (UTC)
(編集競合)あまり誰でもできるとしておくと、メタに出向いて虚偽の依頼を行う「荒らし」をローカルから出すのではないか、という点を、当初懸念していたんです。それで、ある程度は絞っておこうかと考えていたんです。でも、「必要なら後で」(自動退任の準用(つまり、管理者=4)で当面は規定して、範囲を広げるなら後で議論を。)というのもいい気もしてきた。。(それが元々の私の意見)--Anonymous000 2006年11月19日 (日) 11:10 (UTC)メンテのため上記Ks aka 98さんのコメントとともに場所を移動・--Anonymous000 2006年11月19日 (日) 11:33 (UTC)・少し修正2006年11月19日 (日) 11:43 (UTC)・明確化のため下線部追加--Anonymous000 2006年11月20日 (月) 13:30 (UTC)
(補足)リンク先(Anonymous000 2006年11月18日 (土) 03:33 (UTC)のコメント)をご参照下さい。多分趣味の問題。。(コミュニティに強要するわけではないです)--Anonymous000 2006年11月19日 (日) 11:43 (UTC)・コメントを特定するため日付を追加--Anonymous000 2006年11月20日 (月) 13:30 (UTC)
  • (意見)選択肢のどれにもあてはまらないのですが、調停委員会ができるまでは「他の利用者を管理者にする(こちらご参照のこと)」ことのできるビューロクラットが、メタに申請にいくのが適切ではないかと思いました。理由としては、一般の管理者よりメタでの信頼度が高いと思われること、複数いらっしゃるのでどなたかがいっていただければ、個人の負担になることは少ないだろうと思われることです。Toki-ho 2006年11月20日 (月) 00:01 (UTC)
    • (コメント)ビューロクラットだと確かに「信頼度は抜群!」なのですが、全部で4名しかおらず(スチュワードでもあるSuisuiさんは除外)、そのうちの数名は活動が月1回程度になっており(もちろん、「それが悪い」という意図は私にはありません)、「非常に忙しい」と随所で見聞きする残り数名の方に処理をお願いするのは「(非常に)負担になるのではないか?」というのが私見です(4名の個人名は省きますが、投稿履歴等は確認しました)。このため、「(ビューロクラットのみというのは)ちょっと絞りすぎかな?」と私は思いますがいかがでしょう?。ひとまず「自動退任規定の準用」(つまり、当面は管理者。広げるなら後で議論)にしてもいい気がしてきました(上の下線部と同じ)。--Anonymous000 2006年11月20日 (月) 13:30 (UTC)
      • (コメント)Anonymous000さんご指摘ありがとうございます。それをうけて少し私の考えを説明させていただきます。Anonymous000さんのご意見にもあったと存じますが、Wikipedia:管理者の解任で解任がきまり、なおかつ本人がメタに申請に行かないというケースは非常に少ないのではないかと思います。現行のビューロクラットのみなさまの活動の少なさをご指摘してくださっていますが、管理者の着任作業など必要なときには遅滞なく動いてくださっているようです。ですのでご懸念のビューロクラットの負担になるようなことはないのではないかと思いました。また、活動がなく自動退任される管理者の場合は、日本語が読めないメタのスチュワードでも当該管理者の活動記録をみれば解任理由が納得できるかと思うのですが、本人の意に反した解任となると、スチュワードも慎重とならざるを得ないのではないかと存じます。さらに、やすとしさんの「新任時にメタに名前が通っている」とのおおせですが、一般の管理者は、最近ではローカルのビューロクラットが着任作業を行うのですから、必ずしも新任時にメタのスチュワードに「その存在をしられ信頼されている」ということはないのではないかと存じます。ですので、自動退任の場合より一層慎重に、ビューロクラットが申請にいったほうが確実ではないかと思った次第です。いかがでしょうか。Toki-ho 2006年11月22日 (水) 04:04 (UTC)
        • (コメント)Toki-hoさまのご意見を取り入れてビューロクラットを「推奨」する規定に変更しました。変更ついでに自動退任の準用を外して「メタに信頼されたユーザー」であれば管理者でなくても良いことにして、#「管理者の解任」規定の追加等の文案を少し加筆してみました。いかがですか?(>皆様)--Anonymous000 2006年11月22日 (水) 10:12 (UTC)


[編集] リクエスト権者の規程に関する提案

下記の文面はご自由にご修正下さい--Anonymous000 2006年11月19日 (日) 11:10 (UTC)・一段下げました・#「管理者の解任」規定の追加等の加筆により、この「文案」の提案者としては、この提案を取り下げて「#「管理者の解任」規定の追加等にしたいなぁ」と心が傾いています。もっとも、「どれでも良いからみんながいいと思うもので決めておこう」というのが一番の私の優先順位です。--Anonymous000 2006年11月20日 (月) 14:17 (UTC)

  1. 管理者を解任する投票結果が確定した後も、当該管理者は自ら自発的にWikipedia:管理者の辞任#自発的な辞職についてに従って、メタ・ウィキペディア(「メタ」と略す)での辞任手続の依頼を行うことができる。
  2. 当該管理者が自ら前項に基づく辞任手続の依頼を行わないときは、次の者の中で、メタにもアカウントを持つ者がm:Requests for permissions#Removal of accessで、当該管理者の辞任手続の依頼を行うことができる。
    • 日本語版ウィキペディアの管理者
    • 当該管理者を解任とすることを確定した投票に先立つ動議を提出した者、又はその動議に賛同した者
  3. 前項までに規定する者が、合理的な期間内にメタでの辞任手続の依頼を行わない場合には、次の者もこれを行うことができる。
    • 日本語版ウィキペディアとメタ・ウィキペディア双方にアカウントを持つ者の中で、メタで辞任手続 (de-adminship) を実際に行うm:Stewardに対して、自身が「信頼されているユーザー」(a trusted person) であることを容易に証明しうると自身が考える者
  4. メタに辞任手続の依頼を行う者は、その手続にあたるメタのStewardに対して、自身が「信頼されているユーザー」(a trusted person) であることを証明する努力を自らするものとする。


  • 修正履歴--2006年11月19日 (日) 10:48 (UTC)作成・「信頼できる」→「信頼されている」--Anonymous000 2006年11月19日 (日) 11:04 (UTC)

Static Wikipedia (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2006 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Static Wikipedia February 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu