Wikipedia‐ノート:管理者の解任/過去ログ2

message: 草案作成をありがとうございました。
ただ一点、動議提出の部分ですが、条件を満たさないユーザーから異議が出そうな気がします。以前ならFamsisさんや木戸信長さん、最近なら「雷」氏やCalebさんなど。
replies: text: ＞条件を満たすログインユーザーに限られる。
もちろん、濫用を防ぐためだとはわかっていますが、ブロック依頼にならって、「無資格ユーザー（IPユーザーを含む）も動議を提出することはできますが、（余計なコメントをつけるなど）提出形式を守らないもの、および資格のあるユーザから24時間以内に賛同のないものは、自動的に失効します。」という形にすることも考えては？　
ほかのページで「辞任しろ！」と繰り返されるよりは、こちらに無資格で動議を提出して、有資格賛同者がいないことを実感してもらった方が早いのではないかと思わないでもありません。そうした方がよいかどうか、自信はないのですが。--miya 2006年2月3日 (金) 00:17 (UTC)

text: 確認ですが、動議提出権は「管理者とは何か」という知識を数値化したものです。ですから異議に対しても理由を示せます。そもそも誰が見ても分かる「荒らし行為」とウィキペディアの事を知らなければ分からない「管理者として不適切な行為」を同列には扱えないと考えます。

text: 個人的な希望を言えば、解任規定は比較的頻繁に用いられることでそれに対する心理的な抵抗が小さくなれば良いなと考えています。それゆえに「ウィキペディアは偏向的な管理人がいるため全体としても偏向している」のような個性的な動議がよく出されるような場であれば、動議提出の条件を実際には引き下げながらも大多数の人には動議提出への心理的な抵抗がむしろ大きくはならないかと懸念します。なお、辞任しろと繰り返されるのが面倒に感じたのならその管理者は自分を解任投票にかければ済む話と思います。実感させるという意味で言えば条件がよりゆるい投票で実数で示されたほうがインパクトは大きいでしょう。tanuki_Z（sysopは偉くない） 2006年2月3日 (金) 00:45 (UTC)
私も動議提出に関して資格は資格を問わない方がよいと考えます。「管理者とは何か」でのチェックは動議承認（一定人数の賛同）の時点で働く訳ですから動議提出の段階で制限する意味はあまりないと思います。動議提出資格の設定において機能するであろう乱立については、「一定期間賛同票なしで無効」のシステムであまり運営サイドに負荷をかけること無く防止可能でしょう。実際に「辞任させたい」と考える方々からコミュニティ意志確認手段を取り上げてしまうと何らかの形でストレスの影響は出てしまいます（実際切望している方がおられますし）。そのような方への説得（コミュニティ意志の提示）もWikipediaの円滑な運営には重要な事だと考えます。本来の制度目的がどうであれ、投稿ブロック依頼のシステムは、この点に関しても機能しており、現状においては有効に働いていると思います。この機能（コミュニティ意志の確認）においては管理者解任と投稿ブロックで差異は存在しないと考えます。最後に、解任動議の心理的ハードルに関してですが、「偏向的な管理者のせいで．．．」と言ったもの含めて、実際に動議提出の数が出された方が低くなるのではないでしょうか、特に動議が幾つか出されて、妥当な結果が得られた後はそういった形に落ち着くと思います。--TEy 2006年2月5日 (日) 03:03 (UTC)

text: ブロック依頼と違いあくまでコメント依頼がまず先に作られるべきであるという前提を改めて主張しておきます。解任規定は議論の場ではなくあくまで投票だけの場にしたいのでそもそもストレスにしろフラストレーションにしろ、それへの直接のはけ口として使われるのは回避したいと思っています。言いたいことがあればまずコメント依頼を使うべきで、その場でそれなりに説得力のある議論を展開さえすれば、ここにいる投票は意識的に多く行われるべきだと思っているような人間が動議を出すことになるでしょう。おそらくこの考えの違いは私が「個性的な」動議は勘弁して欲しいが投票自体はさして忌避する必要がないと思っているのに対して、「個性的な」動議を出すような人間に因縁をつけられたぐらいでは投票を行なう必要はないと思っておられる（ようにみえる）部分から出ているのではないかと思ったりもしました。私の狙いは動議が出されやすくするのみならず投票も行なわれやすくすることにあります。だからこそ馬鹿馬鹿しく繰り返されるだけの動議は最初から排除しておきたいと考えるのです。動議提出を用いた「説得」に関しても「説得」を行う人間が動議を出せばいいだけの話に私には思えます。「説得」なのでしたら当然それをする人間がいるのでしょうから。tanuki_Z（sysopは偉くない） 2006年2月6日 (月) 00:32 (UTC)
replies: text: :ずいぶん経ちましたがそろそろこの論点を終わらせたいので、妥協？的な提案を。まぁ補足がないでもないですが。

text: :大雑把にいうと、私は動議が出しにくくなるかもしれない、またはコメント依頼の代わりに使われないかもしれない、と考えています。一方で、動議提出権がないといって暴れる人が出るかもしれないというのが対する意見です。どちらが起こるか、どちらに備えた方がよりよいかは今判断することはできません。ので起こってから対処するというが今回の提案です。つまり実際に動議提出権がないといって暴れる人が現れれば、それに対処するため一度動議提出の資格を外すことにします。尤もそれでよい結果が出なければまた別の案を考えるなり、この論点を優劣の検討条件から外して考えるなりすることになるでしょうが。

text: :なお、この提案で暫定的に運用するのは私の案の方である理由は、「暴れる人が出る、出ない」の方が「動議を出しにくくなる、そうならない」より実際に起こったかどうか確認しやすいからで他意はありません。tanuki_Z（sysopは偉くない） 2006年4月14日 (金) 09:23 (UTC)
replies: text: ::推論による論議で収束できない状況ですので、試験運用によって改善を目指すのは妥当だと思います。解任手続きの未整備が管理者選出の壁にもなりつつある現状においては、手順整備を前進させる事が必要だと考えます。--TEy 2006年4月14日 (金) 09:56 (UTC)
thread_title: 動議提出資格が無い場合

message: *管理者署名（この1票で投票フェイズに移行します）
確認ですが、「1票で投票フェイズに移行」するのは「当該管理者」だけですね？　ならば
*当該管理者署名（この1票で投票フェイズに移行します）
と書くと、より明快になると思います。--miya 2006年2月3日 (金) 00:17 (UTC)
replies: text: そのとおりと思いますのでそのようにしたら良いと思います。tanuki_Z（sysopは偉くない） 2006年2月3日 (金) 00:45 (UTC)
thread_title: 管理者の1票

message: ルールはみんなが分かるものにするべき。投票の実施の方が分かりやすいと思いますよ。ビスケット柵崎 2006年4月4日 (火) 21:18 (UTC)
replies: text: とりあえずあまり関係無い話題から。「理由を書いてから消すべきだと思う」と書くのは構いませんが即座に「提案してから書き換えるべきだと思う」と返されるだけではないかと思ったりします。ウィキペディアには激しやすい方もおられますので今後は注意された方が良いかと思います。

text: さて本題。分かりやすいほうがよいというのは当然のことで反対される方はおられないでしょう。ですがまず一点目として、そう分かりにくいものでしょうか？　まぁ私に限ればそれほど分かりにくいとは思わなかったから使ったわけで、そうでないといわれればそれまでなのですが。。

text: 二点目。私が戻した理由はこちらなのですが、書きかえは誤解を生む可能性があるからです。まぁ可能性というか実際あの文面では問題が生じているのですが。

text: 書き換えられたのだから当然規定の内容はよく理解されているものとして話を進めます。ご承知のように投票フェイズは投票の実施のみで構成されているわけではなく、投票フェイズへ移行したことの告知、48時間の猶予期間、当該管理者の最終弁論、投票、無効票の除去、有効票の集計などによって構成されています。従ってこれら全体を「投票」と呼べば、実際の投票との間で用語上の混乱を生む虞があります。具体的に言えばビスケット柵崎さんの文面で生じているように、最終弁論を書ける期間が動議が通った後からなのか、投票が始まった後からなのかはっきりしなくなります。

text: 私はフェイズという表現を使うことがそれほど分かりにくいとは考えませんし、これを使わないことによって無用な混乱が生じる可能性があることから、ビスケット柵崎さんの書きかえに反対します。tanuki_Z（sysopは偉くない） 2006年4月7日 (金) 08:42 (UTC)
「提案してから書き換えるべきと返されるだけと思う」と書かれていますが、あなた自身の意見はどうですか？私は荒らしの場合を除き、REVERTには簡単でも説明が必要だと思っています。文章の書き換えであれば、それが即ち意見の表明の代わりとなることがありますが、説明なしのREVERTは逆に誤解や疑問を招くことが多いのではないでしょうか。
この「管理者解任規定」なるものはあなたが大部分を作られたようですが、Wikipediaの空間に放たれた以上は、他の記事と同様に、誰であれ編集するのは自由だと考えます。他の方はあなたに遠慮されていたのかもしれませんが、私はノートでの提案をせずに書き換えを行いました。Wikipediaでは書き換えが即ち提案になっていると思います。自由に編集し、支持されなければ退けられる。それがWikipediaですよね。解任規定の編集においては、その考えで臨んではダメですか？もちろん勝手気ままな編集をしようという意味ではありません。
これまでの経緯を読ませていただいたところ、あなたの草案に対して誰かがノートで意見を述べても、あなたの考えと違うものは結局否定されて通らないことが多かったように感じるのですが違いますか？あなたは人に意見を求めているのか、自力で規定を作り上げるのか、態度をはっきりされてはいかがでしょうか。それをしないために、規定が出来るまで必要以上に時間がかかっているということはありませんか？あなたが一度、自分で完璧と思うものを作り上げて、それをもって皆に可か不可か、信を問うようにした方が話が早いように思います。
私の書き換えで不適切な部分があれば、適切な文章に改める方法は「フェイズ」という単語を用いなくてもあるでしょう。Wikipediaの他の記事と同様に、他の方が問題ないと思えばフェイズを用いた表現に直せば良いでしょう。ビスケット柵崎 2006年4月7日 (金) 15:55 (UTC)

text: 本題と無関係のことに行を費やされご苦労様です。

text: それで反対の根拠をご理解いただけましたか？tanuki_Z（sysopは偉くない） 2006年4月8日 (土) 00:23 (UTC)
（横から失礼）ビスケット柵崎さん、「フェイズ」というカタカナ語は＜段階＞あるいは＜局面＞というニュアンスの言葉だと思います。ですから、「投票フェイズ」と「投票」では意味が異なってしまうでしょう。日本語でぴったりの言葉がないためにTanuki_Zさんはこの言葉をお使いになったのだと思います。ただ、最初のほうで、「フェイズ」の意味を（注）のような形で付記しておいたほうが誤解が起きなくて良いかもしれませんね。--miya 2006年5月1日 (月) 15:20 (UTC)
=== 冒頭の概略説明について ===
書いてみてから上記と関連しているように思えてきたので節にくっつけます。
冒頭の

text: 管理者の解任については動議フェイズと投票フェイズに分かれる。管理者の解任への要求は必ず動議フェイズを経ねばならない。
ですが、わかる人にはわかる文章でそうでない人には不親切と思いますので、下記のような修正を提案します。

text: 管理者の解任を要求する場合、まず動議を提出して解任投票への賛同を募り、一定数の賛同が得られた場合に限り解任投票が行われる。以下、動議提出の手続を「動議フェイズ」と称し、解任投票の手続を「投票フェイズ」と称する。
--Mt.Stone 2006年7月3日 (月) 01:31 (UTC)
replies: text: :その方が分かりやすそうですので変更に賛成します。一応自己弁護しておくとこういうシステムだという紹介の文章として書いたものが実際の運用の文面になっているので。こういうのは自分では気付かないものですね。tanuki_Z（sysopは偉くない） 2006年7月15日 (土) 07:30 (UTC)
thread_title: 「投票フェイズへの移行」か「投票の実施」か

message: 書いてみてから上記と関連しているように思えてきたので節にくっつけます。
冒頭の
replies: text: 管理者の解任については動議フェイズと投票フェイズに分かれる。管理者の解任への要求は必ず動議フェイズを経ねばならない。
ですが、わかる人にはわかる文章でそうでない人には不親切と思いますので、下記のような修正を提案します。

text: 管理者の解任を要求する場合、まず動議を提出して解任投票への賛同を募り、一定数の賛同が得られた場合に限り解任投票が行われる。以下、動議提出の手続を「動議フェイズ」と称し、解任投票の手続を「投票フェイズ」と称する。
--Mt.Stone 2006年7月3日 (月) 01:31 (UTC)
replies: text: :その方が分かりやすそうですので変更に賛成します。一応自己弁護しておくとこういうシステムだという紹介の文章として書いたものが実際の運用の文面になっているので。こういうのは自分では気付かないものですね。tanuki_Z（sysopは偉くない） 2006年7月15日 (土) 07:30 (UTC)
thread_title:  冒頭の概略説明について 

message: 意見を少々。管理者に就任する際は25％以上の反対で却下されるのに対し、こちらは過半数が必要とされる点について、こちらも25％以上にする必要があると感じます。それに関し投票者の制限として、動機フェイズと同等の活動経験のある利用者とすることとし、また管理者権限を持つ者は投票権を持たないとしたほうが良いと思います。--毛抜き 2006年6月28日 (水) 13:25 (UTC)
replies: text: 私も就任と歩調を合わせるべきと思います。半数よりも25％以上が妥当と思います。--X4852 2006年7月4日 (火) 12:24 (UTC)

text: 25パーセントに賛成。--煌々 2006年7月9日 (日) 09:21 (UTC)

text: 私も管理者就任時のハードルである25%に賛成。（現状なら半数以上で信任されるので）半数近くの参加者に不満を買っている管理者が発動する管理者権限は、いつか必ずや問題の火種になると思います。まぁ、この方針を採用するならの話ですが。--Trilingual 2006年7月10日 (月) 01:13 (UTC)
replies: text: :3つの提案全部に一度は説明した記憶がありますがまぁいいとして。

text: :パーセントが違うのは安定のためです。またその後の提案を読む限り理解されているようで蛇足ですが、立候補は立候補者が時期を選べるのでもし不正があるとしたら賛成側にやりやすいと予想できます。それを抑止する意味で反対票の強さは、制定時そんな意図はなかったことを私も知っていますが、悪くないと思います。他方解任は逆なわけで反対票を強くするのには反対です。

text: :次にこれを踏まえた上でと思いますが続く2つの提案について。不正をしにくくするため制限を強化すること自体は直球な考えです。ですが当然ながら意思表示を制限してしまうという大きなマイナスが伴います。加えて、解任投票の資格を絞ることは立候補で信任投票を行なう母体と別の母体を作ることと同義になります。すると立候補の信任では多数の賛成だが解任では特権階級による解任票で解任というようなことにもなりかねません。まぁ起こる可能性はかなり低いでしょうが。これが起こる起こらないではなく妙な階級を作りかねない動きには私は反対です。管理者除外については以前Tamago915さんなどに説明しました。今ならもっとスマートに説明できますがどうせ以前並に長くなるので今回は控えます。tanuki_Z（sysopは偉くない） 2006年7月15日 (土) 07:30 (UTC)
thread_title:  投票について 

message: 現在、草案に対し色々意見が出ている最中ですが、現段階でテストが必要でしょうか？まだ文案が固まっていない段階でなぜ次々に実在の管理者をテストに掛けるのか些か疑問があります。また、草案に意見を述べて居ない人がテストに参加し、草案に意見を述べている人の殆どは参加していません。合意の無い時点の物に対し実在の管理者を対象にするのも些か管理者を揶揄しているようにも思えます。テストの必要性が現段階であるのか否か？その理由をお教えいただけないでしょうか？--X4852 2006年7月4日 (火) 07:59 (UTC)
replies: text: 今回の件については相当のえげつなさを感じますが、草案段階から関係者が大挙してテストした先例としては、定期削除が存在します。--NekoJaNekoJa 2006年7月4日 (火) 08:48 (UTC)
replies: text: :定期削除されたとしても対象は項目・記事そのものであって、また別の人がその項目を立てることの妨げとはしませんが、今回の対象は生きている人間です。いつからウィキペディアは当人の許諾の無い人体実験を容認する場になったのですか？Wikipedia:ウィキペディアは何でないか#コミュニティと違うものに「ウィキペディアは裁判所（あるいは検察庁）ではありません」を追加すべきでは？と思わざるを得ない。--水野白楓 2006年7月4日 (火) 10:24 (UTC)
replies: text: ::死刑にしようというわけじゃないんだし、コミュニティが与えた権限をコミュニティが取り消すことや、その実験的運用をやることが、間違いだとは思いません。

text: ::ただ個人的には、任期制＋再任投票みたいなやつの方が、権限剥奪時の剥奪されるひとのプライドの傷つき方が少ないのじゃないかとは思います。「解任」という方法論の導入と、他方法（任期制＋再任投票など。他にもあるかも）とどちらがいいか。この事態を前に、ちょっと考えてみてもいいかもしれませんね。--Nekosuki600 2006年7月4日 (火) 13:13 (UTC)
replies: text: :::Wikipedia:管理者の解任と無期限ブロック（追放）は、前者はウィキペディア・コミュニティの中における信頼の致命的失墜を伴い、後者はシステム面においてウィキペディア・コミュニティの中では死刑に等しいというのが私の見解です。--水野白楓 2006年7月5日 (水) 00:38 (UTC)

text: :::Toki-hoです。X4852さん、水野白楓と、おおむね同じ感覚をもっております。｢テスト｣自体には反対はしませんが、テストをするなら事前にコミュニティーに広告の上、テストであると明示的にわかる形でおこなうべきであると思います。Wikipedia‐ノート:管理者の解任/Miya 20060701#このテストについてでも意見を述べておりますので、ご覧ください。Toki-ho 2006年7月5日 (水) 00:09 (UTC)
replies: text: ::::新規投稿してわずか数分後には「お前の投稿したのは（一覧+箇条書き）記事にも劣る糞記事で、二度とこんなのを投稿するなヴォケ」という内容のテンプレートを貼られるのも相当なものだと思いますけれどもね。しかも一人でコツコツ性別記入をしていた利用者をよってたかって袋だたきにした直後に、批判的な声を無視して大々的に「実験」を始めたのはどんなものかと思いますよ。結局ウィキペディア日本語版「コミュニティ」はえげつない所なのであって、今回の事件でもそれが示されたのだと得心いたしました。--NekoJaNekoJa 2006年7月5日 (水) 03:56 (UTC)
replies: text: :::::正直ウィキブレイク後に自分をつかってやろうと思っていたので休んでいた間に行われたというのは困惑してます。やるのはいいのですがせめて計画表を事前に提示した方がスムーズなのにとかは思います。tanuki_Z（sysopは偉くない） 2006年7月15日 (土) 07:30 (UTC)
===Wikipedia:投稿ブロック依頼/OpponentにおけるX4852さんの質問について===
Yaky(話/歴)です。反対票を真っ先に投じた者としてお答えします。他の利用者の方、場所に問題がありましたら、お手数ですが然るべき所に移動してしまって下さい。
Tietew氏解任動議のノートを見て頂きたいのですが、テストとして槍玉に上がってしまうことについての問題視はしております。
問題視しているか否かについて、上記の通りお答えしました。--Yaky(話/歴) 2006年7月4日 (火) 13:06 (UTC)
Yakyさんと編集競合になり一番乗りを逸した反対者の猫が好き♪です。場所に問題がありましたら移動をよろしく（おれも、ここでやるのが正しいとは思えない）。
さて。えー、今回のOpponent氏のやり方が望ましいかどうかというと、望ましくはないでしょう（個人的な評価は「へたくそっ！」という感じです）。Tietew氏の対話不足などをめぐる問題意識は、おそらくおれはOpponent氏と共有しているのではないかと思います。しかし対話が成立しない相手に向けて、言葉や行動をエスカレートさせたところで、対話が成立するようになることは考えにくいんですよねえ。
ただですね。Opponent氏の行動に問題があると思うかどうかと、Tietew氏のブロック依頼に賛同するかどうかは、全然シンクロしません。それらは、それぞれ独立して評価すべき問題だと、おれは認識しております。--Nekosuki600 2006年7月4日 (火) 18:01 (UTC)
んーっと、私はブロック依頼とテストの実施は別物として此処では取り扱いたいと思います。ブロック依頼に発展してしまったのもコミュニティーの合意が明確でないままシミュレーションを始めてしまった事が原因と思います。良かれと思っていても実は裏目に出てしまったというのが今回のケースではないかともいます。謝罪などは別物として、原因になった物を取り除けば今回の問題の解決の糸口が見えてくるのではと思います。単純に言えばテストの中止と言うことになります。対話が成立しなければ刺激しない様に避けるのも一つの手だと思います。知らない第3者が見たら本物の審査がされていると疑うような状況でした。草案自体出来上がっていない状況でのテストも無理があると思います。ブロック依頼にしてもシミュレート無しで行ってきたわけですから必要性も有るのかと思います。現在のシミュレートの継続その物が溝を深める結果になっていると思いますので、ブロック依頼に出されたからと言うわけではなく、他の方も指摘されているようにテストの実施がコミュニティに予告されていなかったと言うことによりコミュニティの合意形成が取れていないという理由で中止されてはと思います。--X4852 2006年7月5日 (水) 05:59 (UTC)

text: X4852さん、Opponent氏称するところの「テスト」のスケジュールに本質的な問題があるとお考えでしたら、是非Wikipedia:管理者の解任/Miya_20060701や定期削除も問題にしてください。どちらも十分周知されることがなく、一部の関係者が断行したものです。まあ私はあきらめていますから何もしませんが… --NekoJaNekoJa 2006年7月5日 (水) 11:41 (UTC)
thread_title:  草案段階でテストが必要か？ 

message: Yaky(話/歴)です。反対票を真っ先に投じた者としてお答えします。他の利用者の方、場所に問題がありましたら、お手数ですが然るべき所に移動してしまって下さい。
Tietew氏解任動議のノートを見て頂きたいのですが、テストとして槍玉に上がってしまうことについての問題視はしております。
問題視しているか否かについて、上記の通りお答えしました。--Yaky(話/歴) 2006年7月4日 (火) 13:06 (UTC)
Yakyさんと編集競合になり一番乗りを逸した反対者の猫が好き♪です。場所に問題がありましたら移動をよろしく（おれも、ここでやるのが正しいとは思えない）。
さて。えー、今回のOpponent氏のやり方が望ましいかどうかというと、望ましくはないでしょう（個人的な評価は「へたくそっ！」という感じです）。Tietew氏の対話不足などをめぐる問題意識は、おそらくおれはOpponent氏と共有しているのではないかと思います。しかし対話が成立しない相手に向けて、言葉や行動をエスカレートさせたところで、対話が成立するようになることは考えにくいんですよねえ。
ただですね。Opponent氏の行動に問題があると思うかどうかと、Tietew氏のブロック依頼に賛同するかどうかは、全然シンクロしません。それらは、それぞれ独立して評価すべき問題だと、おれは認識しております。--Nekosuki600 2006年7月4日 (火) 18:01 (UTC)
んーっと、私はブロック依頼とテストの実施は別物として此処では取り扱いたいと思います。ブロック依頼に発展してしまったのもコミュニティーの合意が明確でないままシミュレーションを始めてしまった事が原因と思います。良かれと思っていても実は裏目に出てしまったというのが今回のケースではないかともいます。謝罪などは別物として、原因になった物を取り除けば今回の問題の解決の糸口が見えてくるのではと思います。単純に言えばテストの中止と言うことになります。対話が成立しなければ刺激しない様に避けるのも一つの手だと思います。知らない第3者が見たら本物の審査がされていると疑うような状況でした。草案自体出来上がっていない状況でのテストも無理があると思います。ブロック依頼にしてもシミュレート無しで行ってきたわけですから必要性も有るのかと思います。現在のシミュレートの継続その物が溝を深める結果になっていると思いますので、ブロック依頼に出されたからと言うわけではなく、他の方も指摘されているようにテストの実施がコミュニティに予告されていなかったと言うことによりコミュニティの合意形成が取れていないという理由で中止されてはと思います。--X4852 2006年7月5日 (水) 05:59 (UTC)
replies: text: X4852さん、Opponent氏称するところの「テスト」のスケジュールに本質的な問題があるとお考えでしたら、是非Wikipedia:管理者の解任/Miya_20060701や定期削除も問題にしてください。どちらも十分周知されることがなく、一部の関係者が断行したものです。まあ私はあきらめていますから何もしませんが… --NekoJaNekoJa 2006年7月5日 (水) 11:41 (UTC)
thread_title: [[Wikipedia:投稿ブロック依頼/Opponent]]におけるX4852さんの質問について

message: 私はmiyaさんの解任動議において、5票以上の移行賛同を認め、井戸端（告知用）にて2日後に投票が始まる旨の告知を行いました。これは以下の根拠によるものですが、はたして私がやったことがよかったのかどうか、ご意見を伺いたく思います。私が上記措置を行ったのは、以下の理由によるものです。
# 投票にあたっては告知を行うのが適切であると思われるため
# 告知から一定の猶予期間、すなわち検討する時間が必要であると思われるため（現ルールでは48時間となっています）
# 5票の時点+48hで自動的に投票フェイズに移行する、と解釈すると、告知のタイミングによっては「猶予期間」が短くなるか、または投票フェイズにまで割り込んでしまうと思ったため
などです。ご検討をよろしくお願いします。S kitahashi(Plé)2006年7月5日 (水) 19:30 (UTC)
replies: text: 適切だと思います。そして、投票フェイズの進行にはそう書いてあるように読めます。

text: 一方、動議フェイズの進行には「5票を越えた時点で投票フェイズに移行する」とあり、一貫していません。また、「5票を越えた」では6票必要となり、そのすぐ下の「5票を得ない」と一貫しません。

text: おそらく「5票を越えた時点で投票フェイズに移行する」を「5票以上得られることを、投票フェイズへの移行条件とする」とでも修正するのが宜しいかと思います。 --Kanjy 2006年7月5日 (水) 19:43 (UTC)

text: 「5票を越えた」だと曖昧ですね「5票以上」だと5票で条件を満たします。しかし、5票は余りにも少ないです。単純に意味もなく「気にいらねぇ～」って言う程度の理由で集まってしまう数字と思います。せめて10票程度にした方が良いと思います。--X4852 2006年7月7日 (金) 03:44 (UTC)
replies: text: :その後に投票フェイズがあり、投票フェイズでは「10票以上の賛成を得て、かつ賛成票が反対票を上回る」事が解任の条件となりますから、5票という数は決して少なくはないのではありませんか？　また、「気にいらねぇ～」で票が集まってしまう管理者と言うのも、それはそれで問題がある気もします（理由なく気に入らないということは無いでしょうし）。　必要票数や、そもそもこのまま解任制度を作る方向で行くのか、あるいは任期＆再信任制などの別制度を導入するかなどは、新しい節を作って提案するのがいいかもしれません。--Yaky(話/歴) 2006年7月7日 (金) 04:48 (UTC)
replies: text: ::依頼者が投票フェイズに移行するための事前投票での5票に含まれるのかも曖昧です。たね 2006年7月7日 (金) 05:24 (UTC)
replies: text: :::この点については、他の投票でも主張していますが、問題提起者は改めて投票をするという方法を求めたい。コミュニティの意思確認のために問題提起をするというのはあり得ますので。まあ動議の場合、提出者が賛同していないというケースは考えにくいかもしれませんが、念押しという意味で「投票をしてはじめて一票とカウント」でいいんじゃなかろうか。--Nekosuki600 2006年7月9日 (日) 03:43 (UTC)
replies: text: ::::動議に関しては発議した人は投票フェイズへの賛同票を投じることができないくらいがいいんじゃないでしょうか。発議人の主張はバイアスが掛かっている可能性が考えられ、その人の票を賛同票に含めると実質4票で投票フェイズに持ち込めることになります。発議理由が正当であるかどうかの判断が微妙な場合、実質4票か5票かは結果を左右することもあると思われます。解任投票の権利は当然あるとしても、動議への賛同票の中に発議人の票を含めると不公平だと思う人が出るかもしれません。手続きの正当性を十分に確保する必要を考えた場合、含めない方が適当だと思うのですが、どうでしょうか。--Mt.Stone 2006年7月9日 (日) 15:34 (UTC)
replies: text: :::::え～。「問題提起＝特定の方向への意思表示」とすることで話がわかりにくくなるのは他のところでも山ほど発生しており、問題提起と意思表示（投票）は別にすべきだと思います。つまり、問題提起者も改めて投票すべしということです。んで、あとは「5人の意思が一致していれば」か「6人の意思が一致していれば」かという違いになりますが、もちろんぎりぎりの賛同者しかいない場合には投票フェイズに移行するかどうかを左右しますけれども、ぎりぎりしかいないんだったら投票に持ち込んだところで罷免されるということは考えにくいんで、結論は変わらないんじゃないでしょうか。審議までの敷居を上げることのメリットが考えにくいし「6票以上獲得したら」とかに直しても「なぜ6人なのか」という疑問が出るだけだと思いますので、「問題提起者も投票できる」「5票以上の賛同があれば動議は通し」でいいと思います（念のためですが、解任動議という方法がいいかどうかというのは別問題です。解任動議という方法を採用するのならば、という前提つきの意見）。--Nekosuki600 2006年7月9日 (日) 15:59 (UTC)
replies: text: ::::::「問題提起≠特定の方向への意思表示」だというのは同じ見解だと思うのですが、その後の取り扱いが正反対なんだと思います（苦笑）。投票フェイズへの賛同票にしても「解任賛成だから投票すべし」と「解任反対だが投票やむなし」の判断が混在することでしょう。そうであるなら尚更、バイアスが掛かっているかもしれない発議人は賛同票の採決には加わらないようにした方が透明性が高いと思うんですよね。これは賛同者数を5から6に変えるということとは質的に違うと思います。「微妙な判断だったら罷免は考えにくい」についても、公的な対面の会議において審議入りの賛否には加わらなくて審議の採決には加わるケースは日常的に見受けられます。解任審議に入ってから投票行動が変わることも十分に考えられるので、上記説についても現状では「経験則ではそうであると考えられる」程度だと思われます。--Mt.Stone 2006年7月9日 (日) 16:37 (UTC)
replies: text: :::::::え～、「質的な違いがあるかどうか」ですが、まあレトリックとしてはそういうことも不可能ではないにせよ、現実には「（投票への）賛同者が5人必要なのか、6人必要なのか」という以上の違いは生じません。--Nekosuki600 2006年7月15日 (土) 12:12 (UTC)
（インデント戻し）Tietew氏のテストケースを見て、管理者解任に反対の人は投票フェイズ移行への賛成票を入れないのではないでしょうか？これも本人に承諾を得ずに行ったテストケースの収穫であると考えていいのじゃないでしょうか？--Trilingual 2006年7月10日 (月) 01:13 (UTC)

text: その見解を否定はしませんが、この場合は承諾が無かったテストケースであるが故に途中から「賛成でも意思表示がしづらい」雰囲気であったように思います。動議フェイズがなんのためにあるのか、考えることが重要です。動議フェイズはプレ投票ではなく、プレ投票であるのなら動議フェイズは不要というのが私の考えです。--Mt.Stone 2006年7月10日 (月) 01:53 (UTC)
replies: text: :本来動議フェイズは、動議に賛同するか否かを投票すべきところであり、miya氏のテストケースが本来予定（予想）された流れだったのでしょうが、miya氏の場合あらかじめ引かれた線路の上を走っていただけで、本来テストで求めていたもの（想定外のもの）が余り浮き彫りになってなかったように感じます。逆に、スタートから想定外であったTietew氏のテストケースでは、様々な面においていいのか悪いのか将来運営していく（予定の）上での問題点が出てきました。そのうちの1つとして、動議フェイズの機能性も存在自体が疑わしいのではないか？（Mt.Stone氏の言葉を借りれば、「プレ投票」のようになってませんか）と思うのです。--Trilingual 2006年7月10日 (月) 04:20 (UTC)

text: :動議を議案として取り上げるためにごく少数の賛成を求めるのは、少数意見を潰してしまわないための手法として公的な会議や議会で導入されている方法です。管理者投票での票数を見ても投票フェイズに移行するための5票は十分な数だと思います（10票だとハードルが高すぎると思います）。個人的な感覚では、10件の依頼で8～9件が投票フェイズに移行するくらいがちょうど良いと思っています。ただし、これには依頼者の票を含めないようにするといった制限は必要かと思いますが。むしろ、投票フェイズに移行した際に被依頼者が十分に弁明する機会を与えることや、解任に至らなかった場合、同じ理由での再依頼を認めるのか認めないのかといった辺りを整備する必要があると思います。--Mt.Stone 2006年7月7日 (金) 06:12 (UTC)
replies: text: ::えっととりあえず論点外してる可能性大ですが「5票を越えて」は5票以上と同義のつもりでした、混乱を招いてごめんなさい。

text: ::動議提出者及び賛同者は解任に解任賛成票を投じる必要はないというのはどこかで説明したと思ったのですが不明瞭でしたでしょうか。一応意図としてはただゲリラ的にやるより手続きを踏んだ方が通りやすくするための仕組みというものもあります。

text: ::opponentさんの件はまだ全部読んでないので申し訳ないのですが、突然やったから賛同しないということと実際の投票で反対票を投じるから賛同しないを混同するのはまずいのではないかと述べておきます。私がそういう考え方の人間ですので。

text: ::最後に個人的にはあるバイアスを見極めていちいち排除していくよりは全部ひっくるめることで意見の調整をするべきという考え方を持っています。ので発議者の排除も管理者の排除同様反対です。tanuki_Z（sysopは偉くない） 2006年7月15日 (土) 07:30 (UTC)
thread_title:  投票フェイズへの移行をめぐる諸問題 

message: 利用者‐会話:霧木諒二#Miyaさんの件の続きとして書きます。
miyaさんの件については、2つの点で非常に誤解を招きやすいことが起こりました。ひとつは、テストであるならばそれをしつこいまでに明示する必要があるのに、それがされていないこと。どのようなテストであるのか、明示されていないこと。もし火災避難訓練を「訓練です」と言わずに始めたら、どれだけ混乱するか考えればわかります。
もうひとつは、「草案でもきちんと場所を作って解任賛成派が圧倒的だったら「草案だから無効」なんて言い訳できないでしょう。」という解釈です。これもテストであることが明示されていないせいと思いますが、「テスト」と思って投票するのと、「本番」と思って投票するのでは、投票行動は全く異なるはずです。わたしだったら、テストの場合、テストをテストとして成立させたいが為に、本心と逆の投票をするかもしれません。ですから、てすとであるなら、どんな結果だろうとそれにわずかなりとも有効性があるはずがありません。また、「拘束されない」という表現もよくないと思います。「拘束されない」とは、前提としてその結果は結果として受け止める、というニュアンスがあります。
私からのお願いは、テストはテストとして明示すること、テストである以上、結果に「拘束されない」のではなくて、結果には実際の意味はまったくないと明言すること、以上です。--っ 2006年7月7日 (金) 05:22 (UTC)
thread_title: 投票のテストについて

message: Miyaさんの解任テストはすでに投票に入っておりますし、Tiewtewさんの方もいつ投票フェーズに進んでもおかしくありません。そこで、この2件についてはともかく、3件目以降のテストの中止を求めます。かなり良いデータが取れましたし、これ以上テストを追加するのではなく、「管理者の解任」手続きの整備に移ることを提案します。コミュニティの意思として3件目以降の中止を提案しておかないとテストどころではなくなってしまいますから。---Redattore 2006年7月7日 (金) 15:50 (UTC)
thread_title:  これ以上のテストの中止を求める 

message: なぜコメント欄がないのですか？--煌々 2006年7月10日 (月) 11:01 (UTC)
replies: text: コメント欄を使った論争が容易に予想できるからです。解任の場合は普通はコメント依頼がたっていると思うのでそちらが使えますし。コメント依頼を解任投票の前に使ってほしいという意図も込めていたりします。tanuki_Z（sysopは偉くない） 2006年7月15日 (土) 07:30 (UTC)
thread_title:  コメント欄 

message: miya氏のテストケース及びTietew氏のテストケースを踏まえたフィードバックは行われないのでしょうか？できれば今回のテストケースを提案された霧木諒二氏等に仕切ってもらいたいのですが。miya氏の終了宣言などもなく、ほったらかされたままなのですが。もう過去のこと？--Trilingual 2006年7月12日 (水) 03:05 (UTC)
thread_title:  フィードバック