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)』

過去ログ:


目次

[編集] 信任成立条件の見直し

以前に提案されたことの繰り返しですが、信任成立条件の見直しを提案します。

現在は

投票期間が終了した時点で、10票以上かつ有効投票の内4分の3以上の賛成票を得た場合に候補者は信任されます。

となっておりますが、1年前でもこれでは少ないのではないかという指摘がありました。この上限をあげることを提案します。現在のコミュニティの規模だと10票は少ないのではないかと思います。

また、現在明文化されていないビューロクラットの信任についても、あらためて文章にすることを提案します。管理者信任と少なくとも同数、あるいはそれ以上(例:2倍)が慣行となっているように思いますが、この点実際に判断をされているビューロクラットの方にご意見を願います(特別な発言権があると考えているわけではないですが、これまでの実施に異議が出ていない以上、方針化にあたり現在の慣行をあまり離れないことも考慮に値する点ではないかと思います)。--Aphaia 2005年11月9日 (水) 04:35 (UTC)

不勉強で、他言語版がどのような基準になっているのか知らないのですが、日本語版に関していうと
  • ログインユーザの割合が少ない = 投票権を持つユーザがコミュニティの規模に対して少ない
  • 管理者の絶対数が不足していると言われている
という状況ですので、もうしばらく現状の基準のままにしておくのがよいのではないでしょうか。ビューロクラットの信任基準の明文化については提案に同意します。どのような基準にするかは他の方の意見を聞きたいと思います。--Tamago915 2005年11月9日 (水) 23:58 (UTC)
確かにログインユーザの割合は少ないのですが、1月に100回以上の編集があるユーザアカウントは100から150程度、5回以上では600から800と記憶しています(数ヶ月前のデータです)。投票権のあるユーザはそれほど少なくはありません。また現在のルールにして以来、20票以下で信任された管理者(Bureaucratではなく)は1人か2人いるかいないかと記憶しています。おっしゃるような懸念はないものと考えています。--Aphaia 2005年11月10日 (木) 01:09 (UTC)

何のために「3/4以上」という基準を設けているのでしょうか?現状でも10票の賛成があっても4票反対があれば管理者には選出されないわけですが…。基準を変更したい人は、

  1. 反対票を入れたくないのですか?
  2. 頭の悪い立候補者に反対票を入れて落選した立候補者からストーカー行為をされるのを懸念されているのですか?
  3. 自分達の立場(地位・階層と言い換えても構いません)を上げたいのですか?

--Goki 2005年11月13日 (日) 02:00 (UTC)

えーと。どこからこういう下種な発想が沸くのでしょうか。これは率直な感想なので、答えてくださらなくてもよいです。
ルールを変える意義はふたつほどあります。
  1. プロジェクトの規模とみあった基準にする。ある言語版でSysopであるということは、それなりにプロジェクトの上で重みを持っています(もちろんそれだけでは足りませんが)。プロジェクトの中で一般に求められている基準からすると、いまの10票というのは少ない。これはすでに昨年の12月に別の方から提案されていたことです。
  2. もうひとつは、15票/30票という基準をあげることで、Checkuserの選出基準を「ビューロクラットに準じる」とひとことで書くことができます。ルールを出来るだけ簡明に保つことにはそれ自体に意義があると考えています。なお、この最低30票というのは財団の方針として提示されていることなので、Checkuserについては動かせない数字です。方針ではもう少し低い数字もでていますが、後の説明で「方針の例示はそのくらいの(25から30の)人数の定期的な投稿者がいるプロジェクトでの最低限の基準」ということなので、Jawikiについては少なくとも30票が要求されると解釈しています。--Aphaia 2005年11月13日 (日) 06:15 (UTC)
投票では、20票以上は確実に見込めますし、最近では反対票だけで20票がはいるくらいで、その20票の内訳が15票-5票でも管理者にはなれるのですから15票に最低ラインをあげても問題ないと考えます。なお、私はストーカーや地位を上げる事に興味は有りません、Wikipedianとして立候補してくださった方に反対票を必要以上にいれるのは好きではありませんが、この基準変更を支持する理由ではありません。--Snow steed 2005年11月13日 (日) 06:32 (UTC)

という理由をはじめから挙げればよいのです。あとは、現在の管理者には適用しないのですか?ということくらいですね。(別に引き上げた基準でも問題ない方々は別ですが。)--Goki 2005年11月13日 (日) 08:37 (UTC)

もともと管理者の信任は明確な投票導入以前はコミュニティの総意が求められていたわけなので、規模に合わせて必要票数を上げること自体には賛成です。ただこの意見は投票導入以前に管理者になった人間が言うとどうにもよろしくないので今まで書きませんでしたが。。
現在の管理者については、他の方の同意があればの話ですが解任規定ができ次第運用の実験の意味を含めて片っ端から解任規定にかけて再信任をやれたらいいなぁと思っていたりしています。tanuki_Z(sysopは偉くない) 2005年11月13日 (日) 09:45 (UTC)

念のために書いておきます。今回に限ってはCheckuserの選出基準云々という合理的な理由があったので了解しましたが、「ユーザ規模に合わせて必要票数を上げる」ことには賛成しているわけではありません。理由は

  • ユーザ規模に合った妥当な必要票数というのが客観的な数字で表せるのか甚だ疑問である。
  • 必要票数を上げる行為自体が新参者にとって階層の壁を感じさせる。
  • 3/4の賛成という規定があるため管理者にふさわしくないユーザに対しては反対票を入れれば済むことである。

からです。--Goki 2005年11月13日 (日) 10:15 (UTC)

私も今回の動きには疑問を感じます。現状の規定で問題が発生しているわけではないのに、規定を厳しく変更することにどういう意義があるのか、よくわからないというのがいちばんの理由です。上のほうで述べたとおり、管理者の数が少ないという現状があるので、規定を緩くするのなら意味はあると思うのですが。正直なところ、一定の基準(例えば、投稿歴1年以上、投稿数2000以上など)を満たしたユーザに自動的に管理者権限を与えるくらいでいいかなと思っているくらいです。--Tamago915 2005年11月13日 (日) 10:41 (UTC)
前回の投票から15票案というのはあるので、別に疑問を感じる所は無いと思いますよ。Sketch氏以降の投票数を見ても20票を下回ったことはないのですから、15票にしようと言う意見がでてもおかしくないでしょう。あと、投稿歴や投稿数を絶対視するのではなく、投稿している内容をきちんと見て判断した方がいいと思います。--Snow steed 2005年11月13日 (日) 11:17 (UTC)

「必要票数を上げる行為自体が新参者にとって階層の壁を感じさせる。」こういう感覚は既に管理者になってる方々や古参の方々には分かりにくいのでしょうね。「投票数を見ても20票を下回ったことはないのですから、15票にしようと言う意見がでてもおかしくない」じゃだめですよ。--Goki 2005年11月13日 (日) 14:40 (UTC)

「上限をあげる」というご提案は、おそらく管理者となるのに必要な賛成票の「下限」を引き上げようというご提案だと推察しますが、現状うまく回っているルールを強いて変更することに合理的な意義を見いだしがたく感じます。下限を引き上げる理由としては、現状の基準により10票前半の賛成で信任された管理者には管理業務を託したくない、といったあたりの主張があり得るかと私は考えましたが、あるいはほかの理由があるでしょうか。

また、「日本語版には管理者が不足している」という主張の方からしてみれば、今回のご提案は管理者が増える可能性を狭めるもので、容認しがたいのではないでしょうか。いずれにせよ、まずは、現状10票としているところをどのように変えたいのか(具体的に何票にしたいという腹案があるのか、それとも今後話し合いで決めたいのか)、そうすることで今後の管理者選任プロセスにどのようなメリットがあるのか、について、提案なさった方またはご賛同の方々にもう少しご説明いただきたいと思います。―sketch/ 2005年11月13日 (日) 15:19 (UTC)

私の理解を。これはSketchさんの求められた説明だけではなくGokiさんの意見への私なりの考えでもあります。
ご承知のように、現在の投票のシステムが導入される前は管理者の信任はコンセンサスによっていました。そして現在の投票はそのコンセンサス制を継承して作られていると理解しています。だからこそ信任システムが変更された際にそれ以前の管理者の信任の正統性を否定して一から選びなおすという手続きを踏まなかったのだと考えています。信任システムが全く別のものになったのでしたら一から選びなおすべきであり、以前のシステムとある程度の連続性があるからこそ以前のシステムによって信任されている管理者の正当性も認めたのだと。尤もこれは私の解釈で他の解釈も考えられますが。
さて、現在検討中の最低限の得票数ですが、これは管理者の信任はコミュニティの一部によって行なわれるべきでなく全体の信任を得るべきであるという考えを反映したものと私は捉えています。そしてこの考えはそれ以前のシステムコンセンサス制に基づいていると。ですからそう理解している私としては否定されるべき「一部」の票数はコミュニティ全体の規模を反映するべきだと考えますので現在の票数よりは増やすべきだという主張を持ちます。ただし、具体的な票数がどれだけであるべきかという点はGokiさんの仰る通り客観的な数字など出ないと考えますので話し合いで決めるべきだと思います。その際その直近で信任された管理者達の得票は一定の参考にはなると思います。
そもそもコンセンサス制の名残という理解をしないで最低得票数を設けること自体、説明はできないと私には思えます。コンセンサス制の名残という理解は、なぜ現在の投票で3/4の得票というきつい条件になっているかを説明するものでもあります。つまり現在の投票での信任の条件とは、具体的な数字にはなっていますが理念としては、コミュニティからの広く厚い賛成があるというものではないかと。そして、最低得票数と3/4の得票の手続きを認め承認している以上、コミュニティはこの理念も承認しているものだと私は今まで思っていました。
以上のような理解を私は持っていますので、現状問題のないシステムをなぜ変えるのかという疑問にも答えることができます。コミュニティの規模を反映していない具体的な「一部」の票数はそもそもの理念に反したもので、従って規模を反映していないこと自体が問題だから、と。
「壁を感じさせる」というのは理解できなくはないのですが、私の理解は以上のものなので規模を反映した適正な値にすることが特段変更以前以上に就任を困難にするものには思えません。この私の考えに対して、やはり感覚が分かりにくいものなのだな、とみられても私としてはどうしようもありません。tanuki_Z(sysopは偉くない) 2005年11月14日 (月) 06:39 (UTC)
それは、信任・選出するための最低票数を引き上げたい理由にはなっていないように思います。具体的な「一部」の票数は、「3/4」の規定により全体の票数が増えれば「一部」の票数は自動的に引き上げられるからです。ですので、最初に
  • 反対票を入れるのがいやなのですか?
とうがった書き方をしたのです。もうひとつ書かせてもらえば、
  • 賛成票を入れるのもいやなのですか?
と言いたくもなるのです。最低票数を引き上げると「黙っていれば」管理者に選任されにくくなるわけですから。--Goki 2005年11月14日 (月) 07:21 (UTC)
(コメント追加)秘密投票では投票が終了した際に賛成票が少ないのに選出されたという事象がありえますが、現在の投票形式だとそうでないので、票の動きに合わせて投票できるので最低票数を引き上げる必要はないと考えます。
不正な投票が疑われた場合にCheckuserを発動できないリスクがあるという理由を除いて、他の最低票数を引き上げる理由には賛同できません。--Goki 2005年11月14日 (月) 07:32 (UTC)
おおむねGokiさんと同様の考えから、やはり引き上げる必要性は薄いと考えました。
まず、コミュニティの規模が拡大しているのならば、最低得票数も上げるべきである、というお話について、下限を上げないと少数の投票だけで管理者が選ばれてしまうことになるから、というような点が根拠として挙がっています。しかし私は逆に、コミュニティの規模が拡大していくのであれば、プロジェクトはそれだけ多くの管理者を必要とするのであり、にもかかわらず規模に応じて信任の下限を引き上げていくと、コミュニティの規模にあった管理者数を確保できなくなってしまうのではないかと思いました。コミュニティの規模がどのようになっても管理者の数が一定数である方が望ましいのであれば、下限の引き上げには納得できますが、そうでないならば、下限は引き上げない方が、適正な管理者数を確保できるのではないでしょうか。この場合、コミュニティの規模に比して少数の投票で信任される管理者が問題視され得ますが、そもそも投票数が少ないようであれば、そのコミュニティはいわば「その程度」のものであり、投票が成立しないような下限は身の丈の合わない設定と言うことになってしまいますし、また投票数が多ければ3/4の基準が有効に機能するので、下限は必要ないことになると思います。
また、コミュニティの規模に応じて下限を引き上げていくのであれば、Aphaiaさんの提案したCheckuserと同一の条件にするという目的は、さらにコミュニティの規模が拡大すれば達成できないことになります。Checkuserと同一の条件にする、というのを主眼にするのであれば、今回だけ引き上げて、以後は引き上げを行わない、とするべきではないかと思います。この点を整理しないまま下限の引き上げを行った場合、今後さらにコミュニティの規模が拡大したときの議論が混乱するように思います。
ところで、Checkuserという言葉はこのノートで突然登場し、以前の議論や機能の紹介へのポインタがないようなのですが、どなたかこれをお示しくだされば幸いです。私の上記の発言は、このノート上に現れたものだけを論点にしていますから、Checkuserという機能の内容や、これに関する過去の議論があれば、意見を変えるかもしれません。よろしくお願いします。―sketch/ 2005年11月14日 (月) 16:15 (UTC)
Wikipedia‐ノート:CheckUserの方針たね 2005年11月14日 (月) 16:19 (UTC)
Sketchさんの視点は私のものとは少し違うのだなと思いました。私が読み違えているのかもしれませんが、管理者の数が確保可能なように制限をゆるやかに保つというふうな御主張があるように思いました。誤読しているようならご訂正を願います。ですが、私は数の確保よりも、「コミュニティから信頼される」ということに疑義の出ない形で信任されえることのほうを重視するべきではないかと考えています。Sysopの第一義は(そのコミュニティにおいて)信頼されているユーザであるということがしばしばWikimedia projectではいわれます。私個人の感覚としては、現在のコミュニティの規模からして、10人というのは少ないと感じています。とくに、ロゴの投票などでは50票を越えるにもかかわらず、Sysopの投票では20票を割り込むことすらある、これは「コミュニティの全体の支持」を得ているとはいえないのではないかと感じます。このあたりの危惧はTanuki Zさんと近いのではないかと思います。そしてこのあたりの感覚は個人によって異なるでしょうし、コミュニティの構成メンバーが異なればかわってくるでしょうから、どのくらいが適正な数であるということは随時見直していくべきではないかと考えています。意見調査をして、現在の数字がより適正であるという方が多いならそれを世論として了解はしますが、Sketchさんら数人が「あげる必要はない」とおっしゃられても、現に不足を感じているものとしては納得はできません。
また、Sketchさんがおっしゃるような政策的な配慮は、果たして有効なものでしょうか。実際に、現在の基準で下限がきいてきた投票はないと記憶しています。また、下限をすえおいたからといって、なりやすさがかわるともいえないのではないでしょうか。実際にはこの基準をめぐる判定がないことから、数字をかえたことで結果には影響しないのかもしれません。しかし感覚の問題として、私には「5人以上の支持、75%」というのでは納得ができない、という思いがあります。1年前同じ議論をしたときには、Snow steedさんが、コミュニティの規模からいって15人では要求が高すぎるといい、多くの人がそれに納得されたという経緯がありました(これは投票で数をみたため、目に見えるかたちで世論があらわれています)。一方、Sketchさんの議論はわたしにとって納得のできるものではなく、現在の基準が適正だという主張もご自身の感覚をでていないように思われます。
Checkuserと同一の条件にする、と私がいったとおっしゃいますが、私が上で提案したのは、BureaucratとCheckuserの条件を同じにすることであって、Sysopではないことにご留意ください。一々あげませんが、細かいところで私の主張を追っていただいていないようにも思います。「Checkuserと同一の条件にする、というのを主眼にするのであれば、今回だけ引き上げて、以後は引き上げを行わない、とするべきではないかと思います。」との御主張ですが、これはどのような論理かわかりませんでした。そもそも、25人から30人というのは「アクティブな投稿者が25人から30人くらいだけいるプロジェクト」における最低限の数字であるという説明が補足としてなされており、Jawikiのような大きなプロジェクトでは、もっと高い水準を要求してもよいだろうと私個人は考えています。英語版などですと、この手の(というのはCheckuserやArbcomのことでSysopのことではありませんが)、重大な権限にかかわる投票では、最低得票数50人や100人を要求するのが通例であり、それを鑑みれば、Jawikiでの投票もプロジェクトの規模に応じて最低得票数の要求などは見直してしかるべきではないかと私は考えています。
一方で、「ある一定範囲の支持があればよい」とする考え方も当然にあって、Sketchさんなどはあるいはそちらに近いのかもしれません。その場合でも、現在の数字は少なすぎるというふうに私などは思います。個人の感覚をいえば、10票75%よりは、20票66%のほうが納得できる、というふうに思います。--Aphaia 2005年11月16日 (水) 10:00 (UTC)

そんなのは10票75%で選出された管理者が不適切な管理者であったときに考えればよいのであって、今下限を引き上げなければならない理由ではないと考えます。(ただし、前段でも書いてますが、Checkuserの件は除きます。)--Goki 2005年11月16日 (水) 10:44 (UTC)

現在の投票状況からすると下限15票でも低いぐらいかもしれないと感じてますが、ひとまず15票に引き上げには賛成します。僕の考えは Tanuki Z さんの意見にかなり近く、繰り返しになるので書きません。ただ、選出方式が変わらなかったとしても、参加者の構成が変わり続ける以上はどのような管理者が信任されるのかも変わってゆくだろうから定期的に再信任投票を行なう制度はあったほうがいいかなと思ってます (Wikipedia‐ノート:管理者の辞任の議論はひそかに応援してます)。「不適切な管理者であったときに考えればよい」については、どうして予防策を立てず積極的に後手へ回るべきであると主張されているのかよくわかりませんでした。―غاز(Ghaz) 2005年11月16日 (水) 14:54 (UTC)
  • 現状予防策がなくても問題であるとは感じていない。(何か問題ありますか?あるなら具体的に述べてください。)
  • 問題を明確にしない予防策は取ったとしても弊害になることが多い。
  • 現在の仕組みでは一度作ってしまった下手な予防策を修正することは容易ではない。

のが理由です。--Goki 2005年11月17日 (木) 02:09 (UTC)(訂正Goki 2005年11月17日 (木) 02:16 (UTC))

「問題発生まで対策を立てる必要はない」と「現状のままでも問題は発生しないので対策する必要はない」は相当に違った意見です。後者が真意であると理解して納得できましたが、今後は自らの考えを的確に表現するように努力してもらいたいと思います。また、強調の使い方や言葉の選択が不必要に攻撃的に感じられますので、その辺も考慮していただけると意見交換がしやすくなるかと。
「現在の仕組みでは一度作ってしまった下手な予防策を修正することは容易ではない」もちょっと理解しがたい意見です。「ルール変更が容易でないのでルール変更に反対」ということでしょうか。「ルール変更が容易でない」ことから導かれる結論は「ルール変更と現状維持のどちらが良いのか慎重に検討して選択しなければならない」であると考えます。
何が問題なのかについては既出のはずですが、僕なりにまとめなおすと「設定されている下限が現状に即していない」ことであり、問題発生が予想されるのではなく既に問題は発生していると認識しています。より具体的な懸念としては「管理者選出が適正なものではないとする批判に耐えられない」および「ほっといても投票が成立するのなら面倒だから投票しないでいいやとか思っちゃう人が多くなる」あたりでしょうか。下限何票が適正と考えるかは人それぞれなので、現状の10票でも適正であると考える人がいても変ではないとは思います。―غاز(Ghaz) 2005年11月17日 (木) 10:40 (UTC)
  • 「管理者選出が適正なものではないとする批判」←批判している方はいますか?
  • 「投票しないでいいやとか思っちゃう人」は下限を引き上げた場合でも出ると思います。(消極的反対という意味で)
--Goki 2005年11月17日 (木) 16:17 (UTC)
批判する者の有無に関わらず、批判に耐えうるシステムを構築することは有意義なことですから「いますか?」と質問することは無意味です。反対票をたくさん集めることには特に意義はないと考えるので、消極的反対が増えても別にいいんじゃないかなと思います。―غاز(Ghaz) 2005年11月22日 (火) 15:31 (UTC)

[編集] 合意できる箇所の再確認

まずは改めて数点確認させてください。

一点目は下限がコミュニティの規模にリンクしている限り現状より特別に管理者の就任が難しくなるものではないこと。例えば、ずっと50票の賛成で信任が通っているコミュニティと5票で信任が通っているコミュニティでは、片方が10票を下限とし他方が1票を下限としていても共に全体に占める割合として捉えるならば1/5であり、一方がなりにくいとは言いがたい。

二点目は一部の支持のみを得て就任する管理者は望ましくないこと。一部というよりも私の言いたいことをより分かりやすく伝えるため今後はこの概念を党派と言い換えます。特定の党派の支持のみで管理者となった人間はコミュニティ全体の管理者としては相応しくなく、正当性に疑問がある人間がさも正当性を持つかのごとく振舞うのはよろしくない。

三点目にその人物に信任を感じていない場合、人は反対票を入れる以外に無関心であったりコメントまでしか行なわない可能性があるということ。

四点目に党派の力は総有効票数にもっとも影響されるものの、下限が低いほどその力は強力であること。なぜなら下限が高ければ党派以外の信任票が必要であり、結果総有効票数が多くならなければ投票が成立しないから。

五点目として仮に「コミュニティの規模」にリンクさせるとして(あくまで仮です)、その指標として使いうるのはその直前数回の投票結果であること。登録ユーザー数はもちろん使えませんし、一日の編集総数は曜日や大きなニュースの有無などノイズが多すぎて規模を素直に計ることはできない。

とりあえずこのあたりはお互いに合意できるのではないかと思い確認の意味で提示させていただきます。これらの内合意できないものがあるのでしたら、結構根本的な価値観の相違ということになりかねませんので。tanuki_Z(sysopは偉くない) 2005年11月19日 (土) 10:45 (UTC)

あえてきついことを書かせていただきますが、私は「サイレント・マジョリティを考える必要はない」「物言わぬ奴のことなんか無視してよい」という考え方です。三点目についてはそういう人がいるかもしれないというのはありますが、そんな可能性は考える必要はないと考えてます。また二点目については、(少なくとも総員同意でなくなって以降に選出された)管理者に対する存在価値の否定だと考えてよいですか?--Goki 2005年11月21日 (月) 16:30 (UTC)
Goki さんは二点目・三点目以外には同意と捉えて良いのでしょうか……。えー、僕としては五点すべてに概ね同意します。投票をしないほどサイレントな人は無視でよいというか、存在自体を確認できないわけで考慮しようがないよね。三点目については、まあ合意はできるでしょうが、今回の議論では特に考慮すべき事柄ではないように思えます。投票してない人の意見は、あくまでも「賛成でも反対でもない」ものとして扱うべきです。二点目について、なぜそのような考えに至るのか全くわからないのですが、管理者に対する存在価値の否定と考えてはいけません。―غاز(Ghaz) 2005年11月22日 (火) 15:31 (UTC)
上記5点ともに前提条件の設定がおかしいと思っているので上記5点については同意も何もありません。論理式で判断すればすべて真ですけどね。とにかく、「ユーザの規模に合わせる(その直前数回の投票結果と言い換えてもかまいません)」という理由のみで、下限を引き上げる提案には私は同意できません。(下限を引き上げたい理由は上記5点以外のもっと根本的な理由があるはずです。)--Goki 2005年11月23日 (水) 14:03 (UTC)
私も今回の提案には同意できない立場です。現状で問題が発生しているとの見解もありましたが、10票ぎりぎりで管理者に任命された人が何らかの問題を起こしているわけではなく、問題は発生していないと考えますので、下限を上げる必要はないと考えています。根本的な理由として考えられるのは、管理者になるための敷居を上げることで管理者の質を固定し、ウィキペディアコミュニティの不安定要素・流動化の要素を事前に除去することだと思いますが、多少不安定であるほうがコミュニティの質は高まると思います。あまり固定化すると、コミュニティが内向きになり、硬直化してしまい、管理者の顔色をうかがうようなことになりかねませんので。--Tamago915 2005年11月23日 (水) 15:02 (UTC)
Tanuki Zさんの挙げる5点はすべてその通りだと思いますが、しかしそれが下限引き上げの理由になるとは思えません。利用者数がいくらであろうとも、現在の制度が困った事態を引き起こすことにはなりえないと思うからです。
仮に投票者が少なく、日本語版ウィキペディアの利用者数からしてみるとずっと少ない投票総数で管理者への立候補の投票が成立したとします。だとしても、それはプロジェクトにおける運営への興味を持つ利用者の割合が少なかったということにすぎません。運営に興味を持つ人が少ないことを嘆くことはあり得ると思いますが、だからといってその投票で信任された方の管理者適正に疑問がもたれるものではないでしょう。また、党派による投票によって管理者が誕生するリスクをTanuki Zさんはおっしゃいますが、そのリスクを軽減するために3/4の規定があるのではないかと思います。全体の1/4の反対があれば管理者になることができないというのは、牽制として充分に働きうる規定です。この規定の下では、ある党派が確実に管理者を誕生させようとすれば、全体の3/4の利用者数を得ていなければならないのですから。この状態で、一定のグループによる管理者投票を疑うのは合理的ではないと私は思います。
むしろ、最低10票の賛成票という規定を引き上げると、現在管理者を多数輩出している党派があったとして、その党派が自らの意向に反する管理者を誕生させまいとすることを容易にします。仮にそういった党派があるのなら、引き上げはむしろするべきではありません。詭弁を擁しますが、現在その存在が明らかでもない「党派」のリスクを挙げるのであれば、このように現在の管理者が結託するリスクもまた考慮に入れなければならないでしょう。―sketch/ 2005年11月24日 (木) 13:16 (UTC)
さらに強調すると「ダンマリを決め込むだけ」で管理者に選出しないようにすることが容易になることも付け加えておきます。--Goki 2005年11月24日 (木) 16:52 (UTC)

質問へのご回答ありがとうございました。質問は合意点を確認するという意図と同時に自分の反駁用の材料集めという意図もありました。また謝罪しておきますが、「一部」を「党派」というイコールでない言葉に置き換えたのは詭弁の一種ではあります。ただ、今回のケースでは「一部」は「党派」を含む概念ですので議論を進める上でさほど大きな問題はないだろうと判断していました。

本題の前にもう一点宣言しておきますが、私はGokiさんたちのいう「現状のシステムで問題ない」と「問題のないものは変える必要はない」というご意見には賛成します。ただその二つの結論として「下限を固定化するべきである」という主張を導くことには同意せず、「下限をコミュニティの規模に合わせ続けるべきである」が導かれるはずだと考えています。

さて本題。以下は一応何らかの留保はあるもののおおむね先の質問には皆さん同意であるとして進めていきたいと思います。ただTamago915さんがまだ「敷居を上げる」という表現を使われいるようなので一点目の確認から始めます。

一点目とは要するに次のようなことです。五点目より規模とはそれ以前の投票の結果を意味するわけですから、即時削除慎重派の(A)さん、即時削除の範囲の広い(B)さん、ブロックに慎重な(C)さん、迅速なブロックこそが利益と考える(D)さん、文科系記事の執筆者(E)さん、数学系記事の執筆者(F)さん、地理系記事執筆者の(G)さんのいずれもが50 or 5票の信任を得てきたとき、次に立候補する(X)さんが10 or 1票を割る確率(当選が難しくなる確率)は同じぐらいのものだろうということです。むしろ、割合でなく実体で考えるならば40票を失う方が4票を失うよりも起こりにくいとさえいえるかもしれません。従って、規模にリンクさせつづけることは「敷居を上げる」ことではありません。せいぜい「敷居を下げない」といえるだけです。ところで、現状で敷居を下げなければ"ならない"のであれば、「下限を固定する」という方法ではなく「下限を引き下げる」という方法を選択しないのはなぜでしょうか? また下限を下げなければ"ならない"のでないならば、なぜ問題のない現状を維持することを問題視して変更を加えるべきだとするのでしょうか?

このように私は「問題のない現状」に「下限を上げる」という変更を加えるべきでないと考えておられる方々に対して「問題のない現状」に「下限を固定する」という変更を加えるべきでないと主張したいと思います。

二点目より管理者はコミュニティの一部(党派)のみの支持ではなく全体の支持が望ましいはずです。しかしこれはGokiさんの仰るように総意でなければならないという極論を意味するものではありません。先に言いましたように私は「現状のシステムで問題ない」と考えています。また、現状のシステムに対して総意でないことを理由とした異論は、Gokiさんが『「管理者選出が適正なものではないとする批判」←批判している方はいますか?』と述べられているように存在してはいません。従って現状のシステムによって選ばれている管理者は正統性を与えられる程度には全体に近いコミュニティの支持を受けていると結論付けることができるはずです。

次に四点目より、下限が小さくなるほど党派の力は強くなります。「現状の問題のないシステム」を維持するのでなく「下限を固定化する」という変更を加えた場合、やがて相対的に下限は下がり党派の力は大きくなるといえます。もちろん日本語版の規模が小さくなっていく傾向があるのでしたら党派の力は増大するといえるかもしれませんが、その代わりにその場合「下限を固定する」という変更は「規模にリンクさせる」という現状と異なり管理者の敷居を上げるという欠点を生むでしょう。ところで、党派の力が大きくなった場合、現状のシステムは一部のみの支持は望ましくないという原則により、「下限の固定」という変更によってそれまで与えていた正当性の根拠が揺らぐとは思いませんか?

これに対して3/4が抑止として機能するという反論があると思います。しかし、三点目より人間は常に反対という投票行動をとるとは限らないわけですから、3/4が機能しないことはありうることでしょう。このことに対してもそれは無関心の者が悪いという反論もあると思います。しかし、五点目より下限で期待される票数はそれまで関心を持ってきた人間の数に基づいているものです。その下限が問題になるようなレベルの投票結果を単純に無関心の責任に帰すべきものでしょうか? 下限が問題になるような投票結果が意味するものは「運営に興味を持つ人が少ないこと」ではありません。その候補への「賛成以外の意思表示」が多数あるという事実です。

このあたりが私が先の質問で導こうとした反駁です。次にSketchさんやGokiさんの反論への反駁も書こうと思ったのですが少し時間がないので次回に。

最後に現状のシステムは皆さんの言うように問題のないものです。そして問題のないものをあえて変更する必要はありません。ならなぜ下限の固定という変更を加える必要があるのでしょうか? 現状問題のないウイルス対策ソフトならそのまま使いつづければよいだけです。このとき意味するのはその後も定期的に定義ファイルを更新するということであって現状の問題のない定義ファイルのままでいつづけることではありません。以前子供の足のサイズより少し大きい運動靴を買って、それが問題ないものであれば次も同じ程度に少し大きいサイズの靴を買えばいいだけです。現状問題がないから、問題が生じていないから全く同じサイズの靴を買うことを意味しません。

Gokiさんのいうように「一度作ってしまった下手な予防策」は変更することが難しいものです。これはとりあえずのスタートとして設定された10票の下限が必要以上に神聖視されていることからも証明されています。下手な予防策を取らず現状を維持するために下限をリンクさせつづけるべきです。何か問題が起こるかもしれないからという漠然とした問題意識への予防策として下限の固定を行なうべきではありません。現状の何が問題なのでしょうか? 何か問題を指摘する人はいますか? いないのであればなぜ固定化しようとするのですか? 下限をリンクさせつづけた結果なにか問題が生じたらそのとき対応するのでは何がいけないのですか? 私にはそれらを疑問に感じます。とりあえずこんなところで。tanuki_Z(sysopは偉くない) 2005年11月26日 (土) 09:19 (UTC)

Tanuki Zさんのおっしゃりようは、乱暴にまとめますと「最低得票数は規模に応じて常時変動させることが当初から見込まれていたのであって、それを10票に固定し続けようと方針を変更しようというのであればその根拠を提示すべきだ」という風に読みました。うまい論の運び方だと思いますが、過去に行われた投票ではこれに関して特に活発な議論が行われたわけではありませんから、片方が一種の立証責任を負い、それができないのであればもう片方に決する、という意味合いの議論にはなりえません。私の考えるところによれば、現状の10票下限という考え方がうまくいっているにもかかわらず、それをあえてコミュニティの規模にリンクさせ続けようという風に方針を変更させようという積極的理由がないので、このまま当初の方針である下限10票を維持し続けるべきだ、という主張もできます。どちらが既存の方針を守ろうとしていて、どちらがそれを変更しようとしているのか、という点で争うのは、もともとこれについて確認された方針などというのがないのですから、いくらやっても無駄な議論でしょう。
一点、下限をコミュニティの規模にリンクさせたときに起こりうる事態について、危惧を表明しておきます。日本語版ウィキペディアのコミュニティ規模は発足以来ずっと拡大してきています。しかし、超長期的に見ると、将来的な日本の人口減少、それに伴う日本語話者の減少などによって、コミュニティの規模が縮小することが想定されます。コミュニティの規模に下限をリンクさせるのであれば、その時には管理者信任の下限を引き下げなければなりません。そのとき、過去に下限に足りずに管理者となることができなかった候補者がいた場合、見送り後に下限を引き下げることは場合によって候補者に不公平感を与えますし、またうがった見方をする参加者から、特定の候補者を救済するための引き下げである、と取られたりしかねません。そういったことを考えると、投票の下限は下方硬直性を持つであろうことが予想されます。結果、コミュニティの規模が縮小したにもかかわらず、適切な下限が設定されないのであれば、管理者になるのに必要以上の障壁が生じることになるでしょう。現実味のない話だと思われるかもしれませんが、ウィキペディアは数十年単位で今後存続していくプロジェクトだと私は考えていますので、決して杞憂ではないと思っています。―sketch/ 2005年11月30日 (水) 15:15 (UTC)

前回の私の話の中身はSketchさんのまとめられたとおりです。そして先の反駁が、どちらも現状維持の点から問題がないなら自分達の意見を選ぶべきだと主張できることを表しているに過ぎない、という点にもある程度同意します。ただこれまでの議論に固定化 = 現状維持の主張が含まれていたので、それに対して一旦逆の見方を提示することも先の目的でした。

ただし下限のリンクと下限の固定化という二つの変更には相違点があることも無視すべきではありません。Gikiさんの言われた通りシステムは硬直化しやすいものです。だからこそ問題が起こったときのための柔軟さを考慮することが必要です。下限のリンクはその数字を客観的に決められない以上、変更するたびに話し合う必要があります。そのとき下限を上げることで問題が起こっていると感じている人間が多ければ引き上げ幅を小さくすることもそのときの数値で固定することも、さらに引き下げることも可能です。これらのいわば消極的な変更は難しいものとは言い切れないのではないでしょうか。他方で固定化した場合に問題が生じたならば、固定化した数値の変更という積極的な変更の動議を出し、議論し、決定せねばなりません。こちらは前者に比べれば難しいのではないでしょうか。私個人は規模から見た場合にあまりにも低い下限ぎりぎりの信任に正当性があるとは思えませんが、それを無視して発生するかもしれない問題への対応の柔軟性だけを考えてもリンクさせる方に利点があるように思われます。

ここで前回予告しておいたSketchさんの引き上げが多数派の野望を満たすとすることへの反論を。多数派は自派が望まない管理者候補に対して棄権を使わなくとも3/4で阻止ができます。確かに目立たない形で使えるかどうかの違いはありますが、多数派の野望は現状のシステムがそもそも阻止できない以上引き上げの際の問題点とするのには無理があります。尤もSketchさんの言いたかったことはあるかどうか分からない危険を想定することの無意味さでしょうが。

次に新しいSketchさんの危惧についてですが、一定の硬直性を持つ可能性は否定しませんがそれが深刻さを持つほどの硬直をもたらすとは私は思っていません。まず第一に以前信任されなかった候補の不満についてですが、立候補回数に制限がない以上今の方が有利と思うのなら今立候補すれば良いだけではないでしょうか。次に下限を下げようとする前には下限は現状維持されているはずです。ということは明示的ではなくてもある程度コミュニティの規模が減少傾向にあることは周知されているのではないでしょうか。つまり「下げる」の前には「上げない」という変更が規模の縮小をアナウンスすると。確かにこの場合でも「上げない」という変更がしにくければ意味はありません。ですが「上げない」というのは変更であって変更ではないわけですからそれほど異論が出るものでもないと思われます。まぁこの危惧はいつか起こるとは私も思っていますが先の話ですから今考えても実際どうなるかは分かるはずもないんですが。

ところでそもそもの話として私とSketchさんやGokiさんと間では下限で信任が否定される頻度の想定、つまり規模に対する下限の位置の認識に大きな違いがあるのではないかと思います。私は下限で引っかかるケースはよほどのことがない限りないと想定しています。これはそれだけ下限は低くあるということでもあります。ですが、Sketchさんの今回の危惧を見てもそうは思っておられないのではないかと感じました。コミュニティが変化するものである以上未来についての保証はできませんが、下限が低めに設定されつづけるのであればSketchさんの想定される危惧は小さいものとはならないでしょうか? そして数値については妥協が成り立ち得ないでしょうか?tanuki_Z(sysopは偉くない) 2005年12月3日 (土) 11:17 (UTC)

お返事が遅くなっていて申し訳ありません。
さて、Tanuki Zさんの4段落目ですが、私は立候補者自身に及ぼす影響より、投票者に及ぼす影響のほうが重要ではないかと思っています。ある人がいったん立候補し、最低得票数に足りず見送りとなった後、最低得票数が引き下げられて再立候補し、当選したとします。このとき、この人の管理者就任に異議を唱えていた方は「この人を当選させるために最低得票数引き下げのための工作が行われたのだ。ウィキペディアで議論を主導するグループが示し合わせて、この人の当選のために引き下げを行ったのだ」と邪推し、ウィキペディアそのものに不信感を抱く、といった可能性があります。このとき、実際に工作が行われたか否かではなくて、そのように思われるか否か、というのが管理の透明性を保つ上で重要になるでしょう。このような恣意的な運用が可能と思わせるシステムにするよりは、常に同一条件であるほうが、より公正さを主張できるのではないでしょうか。
私は、当初の投票時から、最低得票数の下限は設けるべきでない、と思っています。常に3/4の賛成、という一条件で判断するのがよい、と思っているのです。現在の10票という制度が固定化したとき、それを不適切だとするときが来たときに改正するほうがより大変である、とTanuki Zさんはおっしゃいますが、それならば、現在の10票の制限をも撤廃してしまったほうが簡単ではありませんか。それならば、最低得票数の議論に今後費やす人的リソースは0になります。執筆やウィキペディアの質の向上にかかわらない部分に費やす人的リソースは、少ないに越したことはありません。
また、最低得票数がつど適切に設定されるべきである、という考え方なのであれば、その議論が滞ったり、紛糾したりするときに不適切な条件設定による信任が行われる可能性がある、ということになります。常に固定しておけば、そういった事態は発生しえません。以上から、やはり私は最低得票数は変更しないほうが良い、できるならばこの制限は撤廃したほうが良い、という風に思っています。―sketch/ 2005年12月23日 (金) 12:59 (UTC)

[編集] 投票

前回も投票で決めたんですから、今回も投票して決めればよいのでは?--Snow steed 2005年11月24日 (木) 15:34 (UTC)

最終的には投票になるだろう、と思います。ただ、投票前には論点を整理しておく必要があるので、現在のノートはその意味で役に立つだろうと思っています。―sketch/ 2005年11月24日 (木) 16:15 (UTC)
それ(「投票して決めればよい」)は今書くことでしょうか。--Goki 2005年11月24日 (木) 16:52 (UTC)
投票になるにしても議論を尽くしたあとでしょうが、議論を尽くしたとはいえない今提案するべきこととは私も思いません。tanuki_Z(sysopは偉くない) 2005年11月26日 (土) 09:19 (UTC)
これだけ議論してまだ足りないんですか? 端から見ていて時間とページと労力の無駄だと思います。--Snow steed 2005年11月26日 (土) 13:36 (UTC)

「はた」ですか。まあいいですけど。(別に今投票に移行するなという意味じゃなかったんだけど。)--Goki 2005年11月26日 (土) 13:53 (UTC)

投票で決めるほど議論が煮詰まっているようには見えないのですが、現時点でだれがどう考えているか、一度整理してみる値打ちはあるように思います。もし現状維持が多数なら、投票を急ぐ必要もないはずですし。というわけで「Vote」ではなく「Poll」としてご意見をお聞かせください。--miya 2005年12月24日 (土) 19:05 (UTC)
特定の選択肢に「現状維持」の語は与えられないと上で長々と述べているのにそれを無視されるのは特定の意図を持たないと分かっていてもあまり気持ちのいいものではありませんね。tanuki_Z(sysopは偉くない) 2005年12月26日 (月) 08:11 (UTC)
すみません、無視と言うより、特定の選択肢に「現状維持」の語は与えられないとおっしゃっていたとは、読解力不足で分かってませんでした。tanuki_Zさんの見解では「現状のシステム」は「下限をコミュニティの規模に合わせるシステム」で、この「問題のない現状」に「下限を固定する」という変更を加えるべきでないということでしょうか・・・。--miya 2005年12月30日 (金) 13:11 (UTC)

[編集] 意見調査(Poll)

これは意見調査(Poll)です。決定のための正式投票(Vote)ではありません。 賛成できる選択肢に#~~~~で署名をお願いします(複数選択可)。ほかにも望ましい選択肢があれば追加してください。


「75%以上」のみ

(最低得票数は撤廃したほうが良い)

  1. Tamago915 2005年12月25日 (日) 02:33 (UTC)
  2. sketch/ 2005年12月30日 (金) 10:21 (UTC)
  3. miya 2005年12月30日 (金) 13:11 (UTC)


「10票以上かつ75%以上」

(最低得票数を現在の数値で固定)

  1. Taisyo 2005年12月25日 (日) 02:12 (UTC)
  2. Tamago915 2005年12月25日 (日) 02:33 (UTC)
  3. sketch/ 2005年12月30日 (金) 10:21 (UTC)
  4. miya 2005年12月30日 (金) 13:11 (UTC)
  5. Nya0211 2005年12月30日 (金) 13:37 (UTC)
  6. かえで 2006年5月8日 (月) 04:26 (UTC)
  7. Koba-chan 2006年5月12日 (金) 03:34 (UTC)


「15票以上かつ75%以上」にする

(最低得票数引き上げ・投票率据え置き・CheckUser係の1/2)

  1. Ghaz 2005年12月27日 (火) 17:48 (UTC)
  2. miya 2005年12月30日 (金) 13:11 (UTC)
  3. 雪風 2006年1月2日 (月) 13:21 (UTC)
  4. Snow steed 2006年1月4日 (水) 18:30 (UTC)
  5. Nukkie 2006年5月12日 (金) 08:31 (UTC)


「30票以上かつ75%以上」にする

(CheckUser係と同じにして基準を統一・簡略化する)

  1. Tanadesuka 2005年12月25日 (日) 00:23 (UTC)


「下限にコミュニティの規模を反映」かつ「75%以上」にする

最低得票数に規模を反映・投票率据え置き、具体的票数は保留

  1. tanuki_Z(sysopは偉くない) 2005年12月26日 (月) 08:11 (UTC)


「15票以上かつ66%以上」

(最低得票数引き上げ、最低得票率引き下げ)

  1. miya 2005年12月30日 (金) 13:11 (UTC)


「20票以上かつ66%以上」

(最低得票数引き上げ、最低得票率引き下げ)


「20票以上かつ75%以上」にする

(最低得票数引き上げ・投票率据え置き)

  1. 雪風 2006年1月2日 (月) 13:21 (UTC)
  2. 五寸法師 2006年1月4日 (水) 18:27 (UTC)


「25票以上かつ75%以上」にする

(最低得票数引き上げ・投票率据え置き)


「35票もしくはそれ以上」「かつ75%以上」にする

(最低得票数引き上げ・投票率据え置き)


「直近過去5人の管理人当選者の有効投票数平均の50%以上」「かつ75%以上」にする
「その他の案」

(あれば具体的な案を記入願います)

  1. 三菱善次郎 2006年7月23日 (日) 10:49 (UTC) 最低10票で、66%以上 かつ反対が20票未満、管理者は、3票とする

[編集] 立候補/被推薦資格

最近の立候補にからんでルール変更をいわれる方が多いみたいなんですが、どこかですでに議論がはじまっているのでしょうか。てっきりここだと思ったのですが。。もしどこかで始まっているようでしたら、ご案内をいただきたく。--Aphaia 2006年5月15日 (月) 10:22 (UTC)

とりあえず、泡沫候補を締め出すため、及び今までの投票結果を踏まえ、次の条件を満たすログインユーザでなければ立候補できないようにすればどうでしょうか。

  • 初めて編集した時から候補立候補時までに1年以上を経過していること(1年とは立候補が提起された時刻の前年同月同日同時刻を指します)。
  • その間、記事名前空間を600回以上編集し、
  • 候補者の立候補時から遡って直近1ヶ月の記事名前空間の編集回数が5回以上あること(1ヶ月とは立候補が提起された時刻の前月同日同時刻を指します)。
  • 推薦の場合、推薦された者が上記の条件を全て満たすこと

以上の条件は、あくまで草案ですので、ほかに意見があればどしどし述べて下さい。--Seibuabina 2006年5月15日 (月) 13:37 (UTC)

とりあえず…「立候補~編集回数が5回以上」ってのは意味ないです。(当然立候補時刻を知っているので)立候補者が立候補直前に5回編集すればいいだけで…。たね 2006年5月15日 (月) 14:55 (UTC)
ログインユーザとなってから1年、と言うのは長すぎるのではないでしょうか。全て調べたわけではないですが、過去にも1年未満で管理者になった方はいるのではないかと思います。私見では半年以上が妥当ではないかと考えます。
編集回数に関してはむしろ直近3ヶ月に50回ずつ、と言うような、継続した活動があることを条件にしてはどうかと考えています。この50回×3ヶ月と言う行為で、編集回数を稼ぐ行為に出ている場合は事前に投稿ブロックなどで排除されていると考えられるのが理由です。あ、私がこれだと除外だ…まぁ、今立候補する意志はありませんが。
それと、一定期間以上の投稿ブロックを受けたユーザは一定期間の欠格期間があっても良いのかと思います。 Schwarz (/) 2006年5月15日 (月) 15:03 (UTC)
ログインユーザになってから1年って…。論外です。--Goki 2006年5月15日 (月) 15:12 (UTC)
(追記)編集回数も論外ですよ。--Goki 2006年5月15日 (月) 15:21 (UTC)
(某掲示板でくだらない質問してくるひとが出てきたので、回答しておくと)
  1. 今管理者になってる方々は、立候補時点で何回編集されているのか調べましたか?
  2. 今管理者になってる方々は、立候補時点でユーザ登録からどれくらいの期間が経過していたか調べましたか?
ということです。--Goki 2006年5月15日 (月) 15:47 (UTC)
一年は短すぎると思いますがね。Wikipediaでの活動に限らず、ネット歴全体でね。もっとも、ネット歴そのものは他人には調べようがありませんが。--Lonicera 2006年5月15日 (月) 15:51 (UTC)

編集回数や活動期間で機械的に決めるのではなく、例えば供託金制度を設ける、というのはいかがでしょうか。もちろん供託金とは言ってもウィキマネーであって、現金ではありません。

  1. 立候補においては候補者が、推薦においては推薦者が2ウィキを供託する
  2. 供託金は投票終了後に候補者(推薦者)に戻す
  3. ただし、賛成票が5票に満たなかった場合は供託金は没収とする。没収された供託金はTom(_ _)mos Fundに寄付される。

この意図するところは、「初任給」としてウィキマネーを得るにはログインしてから1ヶ月、かつ編集回数200回以上が必要となる、という規定によってRfAにも編集回数や活動期間に自動的に規定を設けることになる一方で、月間感謝賞などによってウィキマネーを得ることができるようなウィキペディアンであるならば、活動期間や編集回数が足らなくてもその活動内容を評価して立候補(推薦)を認めましょう、ということです。また、賛成票数が規定に達しなかった場合にはウィキマネーが没収されるというリスクを負わせることによって、荒らし目的や安易な立候補(推薦)を減らす効果もあるものと思われます(そもそも荒らしがウィキマネーを得られるとも思えません)。Yassie 2006年5月15日 (月) 16:15 (UTC)

私の場合、ウィキマネーは持ってますけど、現状の月間感謝賞のような馴れ合い状況は嫌なんですよね。あと、/sig使いの意見なんか聞く必要ありませんな。:p --Goki 2006年5月15日 (月) 16:23 (UTC)

とにかく、泡沫候補を締め出したい理由を書いてくださいね。現状だって、泡沫候補は適当に反対票が入って排除できているわけだから。--Goki 2006年5月15日 (月) 16:52 (UTC)

泡沫候補を締め出したい理由ですが、ねこださんのような人が次々と立候補されたりしたら、それらにいちいち対処しなければなりませんし、それってかなり面倒ですよね?それなら、最初から締め出したほうがいい訳ですし。--Seibuabina 2006年5月15日 (月) 21:53 (UTC)
補足させていただきます。現状のように煙に巻いたような、曖昧な基準にしておいたのでは、ねこだ様のような「立候補者」がこれからも出てくることが予想されるからです。悪戯目的なのか、ただ単に非常識なだけなのかは別として。特に日本の小・中・高校が夏休みに入りますと、いわゆる「夏厨」が悪戯目的でこのような「立候補」を多数行い、RfAが本来の機能を果たせなくなることも予想されます(たった1週間のゴールデンウィークですらこの有様ですからね)。そうしたことを未然に防ぐため、立候補資格の明確化・明文化をできるだけ早急に行ったほうがよろしいと考えられます。Yassie 2006年5月16日 (火) 00:07 (UTC)
何が面倒なのか理解に苦しみます。明らかに悪戯だったり非常識であると思われるのなら、質問も何もせずに反対欄に「# ~~~~」と書き込むだけで十分です。Wikipedia:管理者への立候補が長大化することが問題だと考えるのでしたら、サブページを埋め込みにしないようにするとか、他の方法を考えるほうがいいのではないでしょうか。―霧木諒二 2006年5月16日 (火) 03:07 (UTC)
管理者への立候補者数など現時点ではたかが知れている。もし制限するとしても現在の投票資格と同じにするだけで良いのでは?(それだけでも泡沫候補を少なからず減らせると思いますが)--水野白楓 2006年5月16日 (火) 03:27 (UTC)

こんなものは曖昧な基準でいいのですよ。明確な線引きを行うと抜け道を探す馬鹿が必ず出てきます。で、それにふたをすればまたその抜け道を探す馬鹿が出る。どんどんくだらないことで規則がややこしくなって、素人には理解できないものになるだけです。--Goki 2006年5月16日 (火) 03:56 (UTC)

(追記)面倒だと思うなら投票に参加しないという手も使えるのに。現状は賛成票が一定数なければ管理者になることはできません。つまり、全員無視すれば管理者にはなれないわけです。--Goki 2006年5月16日 (火) 03:59 (UTC)
私も条件付けにはどちらかというと反対です。この場でも一年は長い/短いという意見が出ていることからも明らかなように少なくとも現状では管理者に求めるものは各々で異なっていると感じています。条件を付けることは結果としてそのうちのあるものを切り捨てることになるのではないかと危惧します。自分にとって「泡沫」なら反対票を投じればいいだけのことでわざわざ事前に切り捨てる意義に疑問を感じます。実際の選挙のように多額の公費がかかるわけでもないですし。
悪戯防止というのであればとりあえず半保護でもかけておいたらいいのではと個人的には思います。tanuki_Z(sysopは偉くない) 2006年5月16日 (火) 05:11 (UTC)
まぁ、「荒らしは放置」というのはネット上(特に日本)ではセオリーなんでしょうけどね...本音を言ってしまうと、RfAという運営上重要な場で、投票には明確な基準があるのに、肝心の立候補/被推薦には曖昧な奨励文しかなく、その曖昧さが気持ち悪かったのですよ。要らないという意見がコミュニティの趨勢なのであれば、無理につける必要もないでしょうね。失礼しました。Yassie 2006年5月16日 (火) 05:38 (UTC)

[編集] 立候補/被推薦資格:資格案

解任動議提出資格に準じて?

Wikipedia:管理者の解任と揃えてはどうでしょうか(向こうも草案ですが)。今の動議提出権は「管理者とは何か」を把握していることを示す数値、とどなたか仰っていたように思います。--Hrk 2006年5月15日 (月) 17:01 (UTC)

いいアイディアだと思います。ウィキペディアのことを良く知らない人たちが簡単に立候補して質疑応答→投票→不信任のプロセスを繰り返すのはリソースの無駄だと思いますので、Wikipedia:管理者の解任#動議提出権者に準じて以下のように定めてはいかがでしょう?
  • 初めて編集した時から推薦・立候補時までに3ヶ月以上を経過していること。
  • その間、記事名前空間を150回以上編集し、
  • 推薦・立候補時から遡って直近1ヶ月の編集回数が10回以上あること。
現sysopの中には、初編集3ヶ月未満で就任した人もいますが、2,3年前と現在では読むべきウィキペディア文書の量も違いますし、同列に考える必要も無いと思われます。--miya 2006年5月16日 (火) 01:01 (UTC)
シンプルにするんだったら、選挙権(これは現在定めがある)と被選挙権(これは現在はあいまいな奨励文になっている)を同一のものにする、という手もあります。上でいわれている基準を、被選挙権だけでなく選挙権にも適応する、というのもひとつの手ではあります。個別規定については、みなおしの必要はあるでしょうが。
もうひとつ、英語版のように「推薦された候補だけを受け入れる」という手もあります。あれは、経験の浅い若い立候補者が続出したために導入された規定なので、状況としてはまあ似ていますね。もっともJAWPでは立候補か推薦かに意欲の濃淡を見る方がいるので、あまりよい規定として作用しない可能性もあるでしょうが。
過去の基準をそのまま現在の基準にしつづけなければいけない、ということはないと思います。この点ではMiyaさんに同意します。
上ででていた「泡沫候補」(ママ)うんぬんのことについては、むしろこうした規定は「泡沫候補」(ママ)そのものについてより、そうしたことをきっかけに騒がずにはおられないかたがたを制止するためのものなのかなあ、と議論をみていて感じました。私個人は、座視していればいいのだと思うのですが、そうした騒ぎもいれればまあいろいろなリソースの無駄であるというのはもっともだなあとも思います。--Aphaia 2006年5月16日 (火) 04:25 (UTC)
解任規定にあのような規定がある理由は動議提出者の無知なり落ち度なりが、本人である動議提出者ではなく動議を出された管理者の投票に影響を与えかねないからです。立候補では推薦にしろ立候補にしろ、無知なり落ち度なりは本人の投票に反映されます。自身の行為の責任は自身が負うべきですが、他人の無知・落ち度で振り回されるのはよろしくありません。そういう理由であの規定は設けてあるので、個人の落ち度でその本人がデメリットを受けることをわざわざ妨げなくてもいいのではと私は思います。tanuki_Z(sysopは偉くない) 2006年5月16日 (火) 05:11 (UTC)
それには同感なんですが、規定はむしろ「振り回される人がいるから、その人たちの保護のために導入することには(一連のごたごたによるリソースの乱費を防ぎ)一定の益がある」ということなんじゃないかと思うのですね。シャリヴァリってえのは一年に一度とか二度とかだから意味があるのであって、恒常化したら逆に無益なんじゃないかというのと似てるかもしれない。
まあ、誰を保護するにせよ、パターナリスティックでかつそれを導入しないことで著しく不利をこうむる人がいるわけでもない規定は無益である。という立場があることには理解できます。一方で、騒ぎがあること自体があることがよろしくない(落ち着いた議論をさまたげ、まじめな立候補者の意欲を減衰させるだろうとかなんとか)という考え方があることも予想されるのです。規定反対の方は、後者についてはいかがお考えですか。--Aphaia 2006年5月16日 (火) 06:32 (UTC)
予想されるというか、そういう考え方の方がいるのであれば意思表示されたらいかがかと。その意思表示があってから議論すればよいことです。(別にAphaiaさんがしろといっているわけではありませんので念のため。)--Goki 2006年5月16日 (火) 08:12 (UTC)

[編集] 立候補資格が明言化されていないことによる不利益

考えられる不利益としては、人的・ハード的リソースの無駄のほか、「見当違いの候補者」が立っている間はまともな人が立候補するのをためらう可能性があげられると思います。また「3ヶ月・150回・直近10回」、最低限これくらいは履歴がないと、候補者の人柄や行動を見定めることができないため賛成票を投じることは難しく、その結果、本当に管理者にふさわしかった人を不信任してしまう可能性もあるでしょう。--miya 2006年5月17日 (水) 09:08 (UTC)

ENWQの経験からいうと、他プロジェクトでの管理者経験のある方の場合、3ヶ月を要求する必要は必ずしもありません。最短で1週間くらいの継続的なメンテナンス参加で推薦を打診したことがありますが、圧倒的な支持で迎えられ、またとてもよく働いていてくださって本当に助かっています(だからこんなところで私も油を売っていられるわけですが)。一方で、Metaあたりだと3ヶ月は少ないという声もたびたび出ますので、この感覚は個人によってもプロジェクトによっても違うのでしょう。大多数の方がどう感じるかをアンケートでみるのがよいだろうと思います。
逆に直近10回は、プロジェクトへの恒常的な参加意欲をみるのには少ないという実感がどのプロジェクトをみてもあります。過去1週間で50くらいはあってほしいというか。。ただこれもその方がどういう傾向の編集をするかでだいぶ異なりますから、現在管理者をしておられる方の編集回数から割り出すくらいでいいのではないでしょうか。一方で個人的な感覚として、この規定はsockpuppetかどうかを判定するのには必要でしょうけど、管理者候補でそういうことがあるとも思えません。あるいはこれは管理者候補についてはそもそもいらない規定かもしれないですね。--Aphaia 2006年5月17日 (水) 10:06 (UTC)

編集競合となりましたので、そのまま意見を以下に投稿します。--Maris stella 2006年5月17日 (水) 10:37 (UTC)

最初の編集から「3ヶ月」というのは、最低でも必要だと思います。一つは、これまでの立候補とその経過を見ていた限りでは、三ヶ月未満の立候補の場合は、「時期尚早」ということで反対票が出てきているという事実があります。また、ウィキペディアはかなり特殊な場所だということも認識する必要があると思います。この特殊さに慣れてもらうためには、最低で三ヶ月、管理者になろうというのなら、本当は半年、一年の経験が必要だとも思いますが、最低期間として、「3ヶ月」は必要だと思います。
次に編集回数は、「500回」以上を要件とするのがよいと思います。3ヶ月だと、一日に一回編集しても90編集で、雑草取りのような編集をしていると、500回というのは簡単にクリアーされます。また管理者は、(失礼な言い方かも知れませんが)或る意味「雑草取り」的な作業を行って戴く訳で、150回では少ないとも思います。
「直近10回」も、「3ヶ月」と同様で、過去一ヶ月で10回の編集もしていなかった人が立候補するというのは不自然です。要するに、ハードルを造るのではなく、過去一年ぐらいの立候補経過を見てきた経験からしますと、こういう条件を満たしていない人は、管理者に信任されにくいということは明らかなので、悪戯などを排除するためにも、この程度の条件を定めることは自然だと思います。(また、追加すれば、「投票」には資格が必要なのに、「立候補」には何の資格も必要でないという現行のありようが不自然だとも思えます)。--Maris stella 2006年5月17日 (水) 10:37 (UTC)

編集競合、意図したわけではないとはいえ、ご迷惑おかけしました。

500回ですか。。もちろんローカルの規則はローカルの事情にあわせるのがいいんですが、ウィキメディア財団の理事に立候補するための最低条件が編集400回で、JAWPの管理者には500回ですか。。なんというか、感無量です。そうハードルがあがるのじゃ、ますますなり手がなくなるんじゃないだろか。
、「投票」には資格が必要なのに、「立候補」には何の資格も必要でない、というのは不自然というのはもっともな指摘です。しかしこれにも一応は「……である人を歓迎する」という弱い抑止がいまでもあるわけです・問題なのは、これをたんなる推奨として無視できる強い心臓の人がいっぱいたくさんいるということなのであって、 とうことは話をまとめるにはひとまずここをいじって「3ヶ月以上」というところだけでも強い規則にする というのも手なんじゃないかと思いました。--Aphaia 2006年5月17日 (水) 10:47 (UTC)

私は「考えられる不利益」をあげて議論したくはありません。仮定で議論しても机上の空論に過ぎません。「考えられる」ではなく「実際にある不利益」があって初めてハードルなどは設定すべきだと考えています。で、実際に不利益をこうむっている方はいるのですかと問うているのです。--Goki 2006年5月17日 (水) 11:23 (UTC)

横から入って恐縮ですが、500回などの具体的な数字についてです。他プロジェクトとの整合性は重視しなくてもよいのではと思います。Wikipedia日本語版には日本語版特有の事情もあることだし(列挙するほど精通しているわけではありませんが)、皆が納得できるところに落ち着けばそれでいいと思います。各々の数字が多いか少ないかという判断は私にはできかねます。むしろ私は推薦人(3人以上、合計編集数5000)を立候補要件として想定していましたが、いまさらこんな話を蒸し返すのもアレなので。ともかく日本語版の現状を第一に数値設定していただければと思います。S kitahashi(Plé)2006年5月17日 (水) 13:10 (UTC)

設定する実際の利益としては、現在のWikipedia:管理者への立候補が陥っているような、悪戯の多くを事前に排除できることが挙げられます。逆に条件を設定することの不利益という面で考えると、「管理者が少なくなる」という懸念に限られると思うのですが、これは条件を「jawikiにおいてそれ以下であればまず確実に当選しないライン」と最低限に設定すれば回避できると考えます。というわけで(?)、その条件ラインの具体的な位置はともかく、立候補の条件は最低限、また有るか無いかで言えば、有った方が利益は多いという2点についてまず合意を形成できないでしょうか。Hrk 2006年5月17日 (水) 21:58 (UTC)

  • 悪戯の多くを事前に排除できること
これって本当にできると思っているのですか?

で、条件を設定しないことの不利益を挙げてください。どなたでもかまいませんから。--Goki 2006年5月18日 (木) 01:30 (UTC)

  • これは逆説的な質問ですが、どうして投票者には資格条件があって立候補者にはないのですか?普通の選挙制度の常識からすれば、被選挙人は選挙人よりもより高い責任が求められるゆえに資格が制限されるのが一般的であり、現在の状態は明らかに矛盾しています。立候補者に資格が不要ならば投票者にも資格条件は不要でなければおかしいという事になると思うのですが。--水野白楓 2006年5月18日 (木) 03:53 (UTC)
先日来みていましたが、話が進みませんね…条件に関しては設定するほうが多数意見のような印象を受けますが、であれば少数意見側には「設定しないほうがいい理由」すなわち積極的に非設定を支持できる理由が求められるのではないかと。このあたりがクリアされないと、小田原評定になるのではないかと危惧します。S kitahashi(Plé)2006年5月18日 (木) 04:16 (UTC)
悪戯の抑止力というのは確実になると思っています。無駄に編集回数を重ねる・事前にアカウントを登録して待つという回避法は確かに存在しますが、安易な悪戯を好むユーザーはそうした面倒な行為を嫌うためです(まあ統計とったわけじゃないですけども)。実際問題として、例えば3ヶ月/150回を掲げれば、現在のWikipedia:管理者への立候補から悪戯(と写る)ユーザーは全員排除できます。不利益としては先の利益をそのまま逆にしただけの、同ユーザーに関わった人達とハード的な「リソースの無駄」に集約されると思います。Hrk 2006年5月18日 (木) 11:16 (UTC)
私個人としての制限が要らないほうの主張を挙げてみます。まず必要といわれる理由への反論から。
Miyaさんの仰る「人的リソースの無駄」ですがすでにGokiさんが言われているとおり嫌なら投票しなければいいだけの話です。わざわざ投票したあと、自分の人的リソースが無駄になったなどというのは冗談にしかなりませんし。本人が自由意志で行動した結果に対して、無駄な立候補がなかった方が各人のリソース配分から考えると良かったと述べるのは物事の優先順位の判断を多くの人間は正しく行なえないとするもので、全体主義的な発想ではないかと思います。
ハード面のほうは否定できませんが、程度の問題と主張することはできます。
「躊躇する」は可能性としては否定できませんがどの程度真実性があるかは私にはわかりません。立証責任は持ち出した方にありますが、現段階で立証できる人は多分いないでしょう。
「本当に管理者にふさわしかった人を不信任」は立候補者本人が行なった行為の結果を本人が取っただけの話ではないでしょうか。また、そのときのコミュニティが不信任にしたのなら、そのときのコミュニティとしては不信任が結論であり「本当」も何もないと思いますけど。そもそも立候補はいつでも何度でも行なえますから、判断材料がそろってから本人がまた立候補すればいいだけではないでしょうか。わざわざ落とされたら可哀想だからといって制限をかけ事前にシャットアウトして「あげる」のは個人の自由意志を制限する過保護なものに思えます。
Maris stellaさんの意見は基本的に全てご自身の感覚を述べているものと思いますが、Maris stellaさんが不適と思われるのでしたら反対し、適当と思われたら賛成すればいいだけの話ではないでしょうか。Maris stellaさんやそれ以前の多くの人間が不適とみなしていた条件をある人に当てはめるとそのときの多数が賛成するということもありうるのですから。ある価値観を持つのがごく少数でもわざわざその価値観を排除する必要はないのではないでしょうか。信任されにくいからは、制限する理由にはならないと思います。
投票に資格が必要なのは投票条件を満たしている人が偉い人で資格が与えられるというのではなく単に不正投票を防止するための手段、と認識していたのですが違ったのでしょうか。立候補者の場合は投票者よりも複数アカウントを使われたときの問題は小さいと思いますから(同一人が複数の立候補をする方が複数の賛否を投ずるより問題は小さい)そこまで異常とは思えません。
悪戯の排除は同意しますが、そのための制限条件としては私ならまず半保護の条件を挙げます。それでも依然として悪戯がなくならないのなら改めてそのための条件を考えるべきでしょう。他の理由に基づいた制限の根拠としてこれを挙げるべきではないと主張します。まぁ、どんな条件をつけても完全に排除なんてできないと思いますから程度問題になるでしょうが。
次に反対の主張を。
まず一例をあげます。管理者立候補には「数ヶ月」の推奨があります。これを私はずっと「3ヶ月」と考えていたのですが、以前の信任の際に「2ヶ月」ととっておられる方がおられました。また、この場では「3ヶ月では短いと思うが」といった意見も見受けられます。さらには「以前と今では期間に関しても同じ条件で考えることはできない」という意見もあります。これらから明らかなことは「期間」一つとっても各人によって適当と考える条件は異なっており、その上その考えは時間と共に変化するということです。
仮に一定期間が必要と決めたとしましょう。するとそれは、ある人はその期間には達していないが今の時点でも賛成に価する、という価値観を認めないことと同じにはならないでしょうか。もちろんそう思うような時期にはそのある人は立候補できないわけですから、こうした価値観があらわになることはありません。したがってこれは詭弁だとか杞憂だとかとも言えるでしょう。ですが、各人の管理者像に一つの枠をはめることは事実です。
もっと現実的な問題を挙げましょう。どうやら「適当な期間」は時間と共に変化するようです。これは裏返せば立候補しても落ちるだけの「不適当な期間」も時間と共に変化するということです。仮に、落ちるだけの立候補を排除するために一定の期間を要求するとしましょう。しかしそれはやがて実情に合わなくなるかもしれません。そのときにやはり要求される一定期間を延ばすことになるのでしょうか? 具体的にどれくらい延ばすかを議論したり投票したりして決定するのでしょうか? それは避けるべき「人的・ハード的リソースの無駄」ではないでしょうか。どちらが無駄として大きいかは私には分かりません。ただ(反対)*~~~~と書くのと、「3ヶ月のままでいい。いや4ヶ月は最低でも必要だろう。切りのいい半年はどうだ?」と書かれるのとどちらが大きいのかは。
制限をつけなくともそのときのコミュニティが不適切と思った候補は見送られます。逆は管理者になります。そのときの「世論」に逆らって短すぎたり少なすぎたりする基準を堅持する人もいるでしょう。逆にあまりにも非現実的といえるような基準で投票する人もいるかもしれません。それでもそのときのコミュニティは「当落」という一つの結論を出すと思います。見送られた人は基準を満たしたあと再度立候補することも出来ます。何か問題ですか?tanuki_Z(sysopは偉くない) 2006年5月19日 (金) 04:47 (UTC)
私の言いたかったことの多くは、tanuki_Zさんが書いてくれました。ありがとうございました。(ちょっと文章が長いですが…。)ちょっと挑発的に書かせていただくと
  • 人的リソースの無駄 … 放っておけばいいのに、自分で騒いでおいて何がリソースの無駄なんだと。
  • ハード面について … 通常記事の編集におけるリソースのほうがよっぽど無駄(プレビュー機能を使用しないで短時間に何度も編集することなど)。程度問題。
  • ルールを変えたいのであれば変えたい理由を明確に書くのが本筋で、逆質問などするまえにまずは質問に答えるべし。答えがないなら要望がないということ。
  • 水野さんの質問に答えると、投票者に制限を加えたのはその必要があったから。立候補者に制限を加えていないのは今までその必要がなかったから。(必要ならその理由を書いてくださいね。)
以上 --Goki 2006年5月19日 (金) 06:16 (UTC)

ハード的リソースは確かに後付に近いところがありました。理由として優先順位は低いので、私からこれを挙げるのは撤回します。

人的リソースの無駄、というのは要するに「防げる悪戯を防がない」ということです。投票していないくせに、と言われると耳が痛いですが、例え悪戯と分かっていても全員が放っておけば当選する恐れが0ではなくなり、幾人かの人が無駄と分かっていても投票しなければなりません。「真面目に管理者を志しているのに期間が足りていないような候補者を、機械的に排除できなかったから反対票を入れる」場合とは、分けて考える必要があると思います。要するに無駄が必要になってしまっている、ということです。

もう端的に言ってしまうと、私は現在候補者ページに載っている3人は3人とも悪戯であったと思います。わずかな期間に3件も悪戯が発生しているわけで、悪戯が多発する兆しがあるといって良い状況でしょう。悪戯のたびに幾人かの人が反対票を入れる必要が発生するより、事前に防げた方が望ましいのは言うまでもないことです。それが半保護のみ、登録1ヶ月、登録半年に500件…といった具体的な内容は別に議論するとして、とにかく「『まず現実的に考えて、真面目な候補者の妨げとはならない』ことを前提とした、最低ラインでの抑止力が条件にある方が良い」として合意できないかなと思います。(私自身はそれが3ヶ月と考えていましたが、議論をお聞きしていると1ヶ月でも良いかなあと思ったりしてる次第です)--Hrk 2006年5月19日 (金) 13:36 (UTC)

  • 立候補の資格として投稿ブロックされた利用者への立候補停止を加えたらどうでしょうか?万が一立候補している途中で、投稿ブロックを受けたらその地点で失格という一文を加えたらどうかと思います。--Ichii-ya 2006年5月25日 (木) 15:31 (UTC)
数字とかを決めようとすると、中々決まらない可能性もあるので取りあえず現在の投票者資格と同じ規定を導入するというのはどうでしょうか?--水野白楓 2006年6月25日 (日) 00:31 (UTC)
立候補している途中で投稿ブロックを受けた人が出たんですが・・・煌々 2006年6月29日 (木) 08:28 (UTC)

[編集] 質疑応答スケジュール

私は現在のスケジュール制になってからこの制度を2度利用したのですが、その感想をここに書き付けておきます。

  • 最初の3日間が質問の受付のみで回答ができないのがややもどかしく感じられました。現にフライングで回答しているケースもちらほら見られます。
  • 回答+追加質問に3日間とってあるわけですが、回答が遅くなると追加質問をする時間がなくなってしまいます(そうすると次の1日も無駄になります)。

よく考えられている制度だと思いますが、そろそろいちど見直してもよい時期ではないかと思います。制限を取っ払って最初の一週間は自由に質疑応答ができるようにするとか、いっそのこと2週間全部を質疑応答+投票+その他のコメント期間にあてるとか。どうすれば良いのかはよくわかりませんが。そもそもボケてるのは私だけなのかも知れません。。。--Brevam 2006年5月17日 (水) 14:54 (UTC)

質疑応答期間と投票期間は切り分けたほうがよいのではと思います。現段階で細部まで提案するのは避けますが、誰かが投票したあとに回答するのはいかがなもんかと思うしだいです。質疑応答n日、投票n日という方法がよいかもしれません。みなさんのご意見はいかがでしょうか。S kitahashi(Plé)2006年5月17日 (水) 16:16 (UTC)

質問・応答・投票は全て分けたほうがよいと思います。そうしないと質問合戦になってしまいますし、質疑応答しながら投票では票の移動が激しくなります。落ち着いた雰囲気で議論をして投票をするのが立候補者・投票者とも進行しやすく、よく考えられたコメントが聞けると思います。現状の改善策としては、

  • 「立候補」→「質問」→「回答・再質問」→「再回答」→「投票」

から

  • 「立候補」→「質問」→「回答」→「再質問」→「再回答」→「投票」

でよいのではないかと思います。たね 2006年5月17日 (水) 16:35 (UTC)

私は

  • 「推薦受諾/立候補」→「質問/回答」→「投票」

でいいと思います。たとえば、「質問/回答」期間の後ろ1日は質問禁止にするとかでもいいでしょう。だいたい、質疑応答の応酬になることを懸念するのは質問する側も回答する側も「へたくそ」だからでしょう。--Goki 2006年5月18日 (木) 01:34 (UTC)

  • たね様案を支持します。理由としては、最初の質問に対する回答を基に、さらに深く突っ込んだ質問をしたいというのは十分あり得るからです。一方、質問合戦を避けるためには、回答・再回答期間中の質問を禁止し、「回答」期間であることをハッキリとさせ、候補者が回答に集中できる環境を用意したほうが良いと思います。同様に質問・再質問期間中の回答も禁止し、候補者が落ち着いて十分に練られた回答をするように仕向けたほうが良いでしょう。加えて、投票前の候補者以外によるコメントはミスディレクションにつながり、候補者に多大な心理的影響を与え、コメント合戦に陥ることも考えられるため、投票時のみにしたほうが良いと思います。Yassie 2006年5月18日 (木) 03:43 (UTC)
少なくとも、質問/回答と、投票期間を切り分けることは、ほぼ固まっている感じですね。私もこれには賛成です。
質問と回答については、有権者:候補者 = N:1 という集中砲火のような構図を考えれば、候補者に落ち着いて回答させてあげるという考え方は重要と思います。
質問禁止の期間を設けるのはわかるのですが、回答禁止の期間は何の役に立つのか今一つ理解できないんですけど…。落ち着いて回答してもらうことに役立っているのでしょうか。それは候補者の自由にさせてはいけないのでしょうか。
Gokiさんの案で、最後の1日か2日ほど質問禁止の期間があれば、それでよかろうと思います。候補者が最後にまとめて回答した場合、再質問ができなくなるという問題はありますが、候補者がそのようにした影響は票数に表れると思います。
たねさんの案も悪くはないと思いますが、ただ、回答禁止が何の役に立つのかは理解できていません。それと、一週間を四つ (ex. 3+1+2+1=7) に区切るのでは細か過ぎるのではないでしょうか。細かく刻み過ぎれば有権者や候補者にとって慌しいと思います。またミスが増えて揉める原因になりそうです。二週間 (ex. 4+3+4+3=14) ぐらいにしないと。
もう一点。回答禁止をやめて最初から回答できる(Goki案を含む)場合、候補者が立候補時に最初からテンプレートの質問とその回答を書いておくことも許してよいと思います。そういう自由も候補者に与えてよいでしょう。もしこのルールがあれば、おはぐろ蜻蛉さんは使ったかもしれません(ご本人に聞かなければわかりませんが)。 --Kanjy 2006年5月30日 (火) 14:44 (UTC)
考えられるパターンとしては、
  1. 「立候補」→「一次質問」→「一次回答・二次質問」→「二次回答」→「投票」(現行
  2. 「立候補」→「一次質問」→「一次回答」→「二次質問」→「二次回答」→「投票」
  3. 「立候補」→「自由質問・回答期間」→「回答期間(1日)」→「投票」
何ですが、違いは質問回答フェイズを区切るかフリーディスカッションになるかです。それぞれ一長一短なのでそれぞれの好みも出てきそうです。たね 2006年5月30日 (火) 15:00 (UTC)
本筋でない瑣末な点の自己フォロー。「候補者が立候補時に最初からテンプレートの質問とその回答を書いておくこと」は元々禁じられていないようですね。 --Kanjy 2006年6月7日 (水) 23:43 (UTC)
本筋に戻って、投票期間前に質問・回答を終えることと、回答期限よりも少し早めに質問を締め切ることの必要性はわかりますので同意します。
質問(および再質問)期間中の回答を禁止すべき理由、禁止することで候補者が落ち着いて十分に練られた回答ができるようになるという根拠について、恐れ入りますが、どなたかご説明頂けませんでしょうか。 --Kanjy 2006年6月8日 (木) 03:53 (UTC)

質問/回答と、投票期間を切り分けることは、ほぼ固まっているとのことですが、フェーズを分割せずに、投票は一週間で決着すべきであるという考えの人間もいることを忘れないでいただきたいです。 前回の投票についてはこちらを参照してください[1]--Snow steed 2006年6月8日 (木) 05:37 (UTC)

[編集] 回答時期のみ自由にしては?

今までの議論を拝見していて「回答時期のみ自由にしては?」と思いました。 これまでも、せっかちに前倒しで答える人や立候補と同時にFAQの答えを掲示する人がいましたが、特には問題なかったように記憶しています。

また、そもそも「質問に回答するかどうかも候補者の自由である」とルールに明記したほうがよいと思います。現在でも、回答が義務だとはどこにも書いてありませんが、一歩進めて明記してはいかがでしょうか。 あの質疑が苦痛なので立候補したくないと言う声をほうぼうで聴きますし、いやがらせや揚げ足取りのような質問にも答えなくてはならないのか?という心配が、立候補を思いとどまらせている要因のひとつになっているような気がします(もちろん、タフなひとはお答えになればよろしいのですが)。 タイミングとしては以下のようになるかと思います。

  • 「立候補」→「一次質問期間」→「二次質問期間」→「回答期間(1日)」→「投票」

説明としてはWikipedia:管理者への立候補#投票の形式を以下のようにします。

  • (第1案)質疑期間は以下のように進行します。
    1. 最初の三日間に「一次質問」を受け付けます。
    2. 次の三日間に「二次質問」を受け付けます。
    3. 追加された質問に対して、候補者が回答するための回答期間の予備日を一日設けます。
    • 候補者はいつ回答してもかまいません。その質問が答える必要の無いものだと考えれば、答えなくてもかまいません(ただしそれが投票結果に影響する可能性は十分考えられます)。

いかがでしょうか。--miya 2006年6月21日 (水) 04:34 (UTC)

(賛成)過去に候補者が事前回答した例があり、かつそれできちんと選考を通過されている例もありますので、この案をそのまま適用してよいように思います。特に不都合は思い当たりませんし、質問が多数寄せられる可能性がある場合は(時間的な余裕を確保するために)前倒し回答が必要になるでしょうから……。 -- かえで 2006年6月21日 (水) 11:40 (UTC)
(賛成)問題ないと思います。--Goki 2006年6月21日 (水) 11:42 (UTC)
今書き換えてよろしいでしょうか? 本来なら立候補者がいない時期に書き換えたほうがよいのですが、これから当分の間は信任プロセスが続くこと、かつ、書き換えても実質的な変更は無きに等しいことから、反対意見が出なければ明日にでも書き換えてはどうかと思います。あるいは、現状の文章の下に併記して「こう変更する案が出ています。ご意見があればノートにお願いします」と注釈をつけたほうがいいでしょうか。--miya 2006年6月22日 (木) 01:56 (UTC)
改正そのものには賛成します。が、反対がないと言い切るには早いと思いますので、書き換えは最初の提案があった21日から1週間おいたほうが良いと思います。提案があるという注を付けることには反対しません。Kinori 2006年6月22日 (木) 02:31 (UTC)
(条件付賛成)総論賛成ですが、一次と二次の違いがわかりにくいので、修正を希望します。修正案を3通り提案します。
  1. 「一次質問にはなるべく最初の(例えば)五日間で回答することを推奨」を追加。
  2. 一次と二次を分けた意図を書き、候補者と有権者に解釈を任す。
  3. 一次と二次の区別を廃止。つまり、連続的に随時質問・随時回答とする。
提案理由を述べます。今の形を踏襲して一次と二次を分けた意図は恐らく「一次質問への回答を踏まえて二次質問を出す」でしょう。ところが、回答時期を完全に自由としており、噛み合っていません。一次二次を分けつつ回答有無も回答時期も自由とすること自体は構いませんが、一読して理解しにくいのです。
三つのうち現行ルールに最も似ているのは2案ですが、実際に施行すればmiya原案と2案と3案はほぼ同じ結果かもしれません。最後に、具体化くださったmiyaさん有難うございます。 --Kanjy 2006年6月22日 (木) 03:17 (UTC)

Kinoriさんのご意見、了解です。Kanjyさんのご指摘を参考に考えてみました。--miya 2006年6月22日 (木) 10:19 (UTC)

  • (第2案)質疑期間は以下のように進行します。
  1. 最初の三日間に「一次質問」を受け付けます。
  2. 次の三日間に「二次質問」を受け付けます。
  3. 最後の一日は予備日とします。
    • 審議の都合上、候補者はそれぞれの質問が出てからから3日以内に答えることが推奨されます。しかし、質問されてすぐ回答してもかまいませんし、またその質問が答える必要の無いものだと考えれば、答えなくてもかまいません(ただし回答しなかった場合、それが投票結果に影響する可能性は十分考えられます)。

但し書きは余計なお世話かも知れませんので、但し書きなしの案も作ってみました。--miya 2006年6月22日 (木) 10:22 (UTC)

  • (第3案:但し書き「(ただし回答しなかった場・・・)」なし)
Kanjyです。せっかく新しい案を作ってくださったのですが、miyaさんの第2案と第3案には反対です。私の指摘は「一次と二次の違いがわかりにくい」だったのですが、言葉足らずだったでしょうか。回答時期の自由化が後退している上に、一次と二次の区別が無意味になっています。
miyaさんの原案は、一次と二次の区別を設けているのに、その違いが表現されていませんでした。現行ルールで最初の3日と次の3日の違いは回答を許すか否かの差ですから、回答時期のみ自由にすれば、最初の3日と次の3日の違いがなくなり、単に質問を6日間受け付けることになります。これが先ほどのKanjy修正3案です。
それでも、回答に対する追加質問を意図して、あえて質問期間を二つに分けなければならないなら、回答時期の自由化にやや逆行するものの、一次質問への回答を早めに誘導することで、一次と二次の違いを明確化するのが適当と考えました。これがKanjy修正1案です。
質問期間を分ける必要があり、かつ、回答時期の自由化という主旨に反する推奨は望ましくないとするならば、せめて一次質問と二次質問の意味を示すべきでしょう。これがKanjy修正2案です。
但し書きの有無は、候補者に回答を促す効果だけではなく、一部または全部無回答の候補者に対する有権者の投票行動に影響を与えそうな気がします。 --Kanjy 2006年6月23日 (金) 14:54 (UTC)

Kanjyさんの考えが理解できたかどうか自信が無いので、第4案までを総合して、Kanjy案をご提示いただければ幸いです。なお、但し書きがあるほうがいいかどうか迷いましたが、少なくとも「十分考えられます」だと、投票者に「答えなかったらそれを十分考えろよ」と指示することになりますね。ということで「ただしそれが投票結果に影響する可能はあります」と中立的にするか、あるいは全く入れないほうがよいかもしれません。--miya 2006年6月23日 (金) 16:30 (UTC)

[編集] 質問回答期間改定案(第4案)

  • 質疑期間は以下のように進行します。
  1. 最初の三日間質問を受け付けます。(一次質問)
  2. 次の三日間に候補者の回答に対する追加の質問を受け付けます。(二次質問)
  3. 追加された質問に対して、候補者が回答するための回答期間の予備日を一日設けます。
    一次質問にはなるべく最初の五日間で回答することを推奨しますが、実際にはいつ回答してもかまいませんし、その質問が答える必要の無いものだと考えれば、答えなくてもかまいません。いつ回答するか、あるいは回答を見合わせるかは候補者の判断に任されます。
一次と二次を分けるか分けないかの方はどうでもいいのですが、答えないでも良いですとわざわざ書くのを馬鹿馬鹿しいと感じるのは私だけなのでしょうか。餓鬼じゃないんだから、答えるのも答えないのも自由でただその結果を受け入れる覚悟だけはしろ、なんてわざわざ書くまでもない当たり前のことにしか思えないのですが。そんなに過保護にしなくともそれが分からない人には分からないでも良いんじゃないかとも思ったりします。と、こんな意見もありかなと。tanuki_Z(sysopは偉くない) 2006年6月24日 (土) 00:03 (UTC)
まぁ過保護だろうと大きなお世話だろうと敷居を低くして、ためらっているsysop適任者に手を上げていただきたい、という切羽詰った状況だと思いますが。--miya 2006年6月24日 (土) 01:23 (UTC)
「わざわざ書く」ことに不利益は無いと思います。それに、過去の立候補者への質問などを見ると「当たり前のこと」という認識は一般的でないようですよ。特に、質問する側が。 -- NiKe 2006年6月24日 (土) 01:27 (UTC)
切羽詰った状況というのは理解しました。ただそれを使うとそうでない状態になったら消して良いですかという提案をするのを妨げられませんね。
NiKeさんのコメントに対しては全て納得できません。「わざわざ書く」ことに不利益はないと仰いますが、それは過保護というのが相手を低く見ていることと同義であるという事を忘れておられます。人を必要以上に低く扱うことは言葉を選ばなければ侮辱であると思います。次に当たり前のことという認識が一般的でないというのにはまずNiKeさんの理解が誤っていないかどうかを指摘しておきます。「質問に答えなくても良い」というのはそのことで文句を言われたり不誠実であるとみなされることまで受けいれるという事です。なのにそのことを「特に質問側が理解していない」と仰る論理がよく分かりません。極端なはなし、質問側はそれを理解していようがしていまいがその後同じ行動をとることはありうることです(さらに言えばそんなことも他人から言われないと理解しない候補者に説明責任云々がどうのこうのといえますがこれは私個人の価値観の話ですね)。おそらく厳しい質問を受ける候補者を庇っての発言とは思いますが微妙に意味のそれたご意見は私の文章が長くなるだけしか効能はないと思います。tanuki_Z(sysopは偉くない) 2006年6月24日 (土) 01:50 (UTC)

(インデント戻します)いつの日か、sysopが多すぎるという状況になったら「ハードルをあげよう」という議論になるかもしれませんね。ま、そのときはそのときです。(日本語版でそういう日が来るのかどうか・・・)--miya 2006年6月24日 (土) 05:54 (UTC)

質問期間を二つにわける必要があるとすれば、第4案には異論ありません。
質問期間を分けない(Kanjy修正3案に基づく)案も出そうかと思いましたが、その前に確認しておきたい点があります。
「その質問には答える必要がないと判断します」とでも言ってくれればよいのですが、単に未回答で放置された質問がいくつも残っている場合はどうしましょう。意図的に未回答ならばよいのですが、機器・回線故障や急病のために投票を延期すべきケースもあり得ます。未回答は未回答として投票に進むということで良い、と考えるべきかどうかちょっと悩んでいます。 --Kanjy 2006年6月27日 (火) 15:04 (UTC)
まったく未回答のまま放置された質問があっても(いちいち気にしていたら進まないので)原則として投票に進むこととし、後に問題(不慮の事故など)が明らかになったら、必要に応じて再投票等を(ビューロクラットの判断で)行う、という考え方で宜しいでしょうか。
第4案でまとまるのなら、敢えて新しい案を出してかき回すようなことは慎みますが、いかがでしょうか。第4案の質問期間を一つにしても、実質的な差は僅かだと思います。 --Kanjy 2006年6月27日 (火) 23:58 (UTC)
未回答については、放置でよいと思います。質問期間を一つにする案については引き続き意見募集するということにして、まずは回答期間に絞って第4案の検討をお願いしたいと思います。--miya 2006年6月28日 (水) 06:24 (UTC)
現在のところ異論がないようですが、どのように正式化しましょうか。Wikipedia:井戸端 (告知) でしょうか。あるいは、それは大げさでしょうか。 --Kanjy 2006年6月30日 (金) 13:51 (UTC)
正式なガイドライン改定を Wikipedia:井戸端 (告知) で告知し、異議待ちを経て正式化したいと思います。宜しいでしょうか。 --Kanjy 2006年7月3日 (月) 13:54 (UTC)
第4案に異論がないまま10日ほど経過しておりますので、Wikipedia:井戸端 (告知)#管理者信任投票の質疑応答スケジュール改定案 で正式化を提案しました。 --Kanjy 2006年7月4日 (火) 06:02 (UTC)
一週間待って異議が出ませんでしたので Template:管理者信任Template:管理者への立候補 に反映しました。今後の管理者立候補/推薦に適用されます。 --Kanjy 2006年7月11日 (火) 12:46 (UTC)

[編集] 推薦時の審議スケジュールの起点について

最近は推薦による管理者就任のケースが多くなっていますが、現行のガイドラインでは推薦時の審議スケジュールの起点について明確な記述が無いように思われます。またそのために、案件ごとに審議の起点が異なってしまっている事態も発生しています。

例えばWikipedia:管理者への立候補/Complex01 20060327では被推薦者が推薦受諾のコメントを記入した時刻が起点となっており、Wikipedia:管理者への立候補/Diagraph01 20060423では推薦者が推薦を公表した時刻が起点となっています。

現状のままですと一番最初に審議スケジュールに記入された時刻が既成事実として受け入れられるのでしょうが、仮に推薦表明時刻が起点となった場合には、被推薦者が(他所にて推薦受諾はしているものの)審議ページでは何ら意思表示が行っていない状態であっても審議が進行してしまう可能性もあります。

そこでこのような曖昧さを回避するため、ガイドラインの「投票の形式」セクションにある質疑期間の部分について、以下のように変更することを提起いたします(太字部分を追加)。

  • 質疑期間は以下のように進行します。
    • 立候補が提起された時刻(推薦の場合は推薦受諾の意思が審議ページに記入された時刻)を起点とし、三日間質問を受け付けます。
    • その後三日間の間に、候補者が回答します。このとき候補者の回答に対する追加の質問を受け付けます。
    • 追加された質問に対して、候補者が回答するための回答期間の予備日を一日設けます。

また、Template:管理者への立候補にある「立候補した時刻」という文言を「立候補/推薦受諾した時刻」という文言に置換することも同時に提起いたします。--Complex01 2006年5月18日 (木) 12:02 (UTC)

この点について明確化することが望ましい、という提言に賛成します。ただ、対案として、立候補と推薦とともに「立候補/推薦ページが提起された時刻」とする案を出しておきます。ただし投票開始までに推薦受諾表明が当該ページでなかった場合、推薦は無効となります。--Aphaia 2006年5月19日 (金) 09:35 (UTC)

「立候補が提起された時刻」というのは、Wikipedia:管理者への立候補に[[Wikipedia:管理者への立候補/利用者:○○ ××]]を貼り付けた時刻ではなく、[[Wikipedia:管理者への立候補/利用者:○○ ××]]そのものを初編集した時刻という事でいいでしょうか?--ECLIPSE!? 2006年7月2日 (日) 08:06 (UTC)

[編集] 「管理者見習い」制度の創設について

利用者‐会話:かえで#管理者立候補依頼を見て驚きました。かなり事態が深刻そうですね……私には時間的余裕がないので、まかり間違って選出されたとしても実効活動を執り行うことができません。その代わりに「管理者見習い」制度について考えてみましたので、実施可能かどうかを検討いただけますでしょうか。

【ルール】
  • 「管理者見習い」は管理者への立候補ページで選出する。選考方法や質問類などは管理者選出と同一にする(本番の管理者立候補時に参考資料として使える)。選出条件はゆるく「最低得票制限なし・50%賛成で選出」あたりが妥当。
  • 「管理者見習い」には管理者権限を割り当てず、権限はただ一つ……各依頼ページに次のコメントをつけるのみ。
  • 【(対処予告)○○時間以内に審議が進まなければ、『○○○』を理由として《○○》対処します。 -- ~~~~】

管理者負荷の軽減を目指すには役立ちません(せいぜい「対処予告」コメントがあるものを優先対処できるぐらいかと)。どちらかというと「管理者適性を見る」ための制度になりそうです。今までは「普通のWikipedianとしての行動」以外に見るべきものがありませんでしたが、こういった制度があれば「管理者としての振るまい」をハッキリと目視確認できるので、「草取り中心の活動をされている方」に対しても正当な評価を下す良い資料となる気がします。


夏休みが始まるまでに何らかの成果を出さねばなりませんので、賛否両論どちらでも構いませんのでご意見をいただき、可能な限り早急に結論を出してみたいと思います。皆様のご意見をお待ちしております。 -- かえで 2006年6月18日 (日) 03:17 (UTC)

質問1: どのような方が立候補すべきですか? 例えば「管理者は荷が重いけど見習いなら」という方でしょうか? 質問2: もしご提案どおりの管理者見習い制度が導入された場合、かえでさんご自身は立候補なさいますか? --Kanjy 2006年6月18日 (日) 03:46 (UTC)
解答1: 「立候補してみたいが選ばれるかどうか不安になっている方」「一度選考に落選してしまったことがある方」が主なターゲットになると思います。前者については自薦しかあり得ませんが、後者については自薦他薦共にあり得るかな、と。文字通り「管理者見習い」ですので、(荷が重いと感じている方は)おそらく管理者見習いにも立候補しないと思います。 解答2: 「管理業務に供する時間も意欲もある」事が前提なので、私にとっての決断を左右する要素にはなり得ません。いまいち自分の中でも「管理者見習い」がどういうポジションにあるべきかがハッキリしないもので、引き続きご意見を頂ければ幸いです。 -- かえで 2006年6月18日 (日) 07:49 (UTC)
予告された対処はどれほどの強制力をもつのですか? そのあとで管理者が実際に対処するとき、違う結論を出すことも充分考えられると思うのですが。
管理行為は、ものによりますけれどそれほど時間をとらないものも多くありますよ。ロールバックや即時削除(とくに履歴が実質的にないもの)は1件あたりの処理に15秒とかかりません。たぶんかえでさんが思っているよりは時間を必要としない作業が多々ありますので、一度やってみるのもいいと思うのですけど。--Aphaia 2006年6月18日 (日) 07:54 (UTC)
予告対処コメントは、本対処に対して何ら強制力を持つべきではないし、その必要もないと思います。管理者が妥当性のある予告対処コメントだと感じればその通りに処置するでしょうし、妥当性がないと感じれば相応のコメントなり対処を行うことになるでしょう。予告対処コメントが何らかの強制力をもつとなれば、それは管理者見習いではなくて「副管理者(Co-Sysop)」に近い性質となり、もし意見の対立があれば逆に時間を浪費することになると思います……あえて選考を行い、かつその結果得られるのが「実効的な効力を持たないコメントをつける権限だけ」というのは妙な話ですが、「明らかに管理者向きではない……というわけではないが、まだ管理者になるには早すぎるのではないか」と言われた(or思っている)方がステップアップするための踏み台としては、ちょうど良い高さになるのではないかと期待しています。
管理行為の件、MediaWikiの処理ではなく私の処理が遅いので……かつて依頼系ページへとコメントをつけたことがあるのですが、あの時期にあったようなフットワークはすべて使い果たしてしまいました。 -- かえで 2006年6月18日 (日) 17:25 (UTC)
賛否どちらのコメントでも良いそうなので。上の質疑を含めて読んでいて今ひとつメリットがよく分かりません。他方、見習いがあるということは、管理者は見習いより偉いと言ってるようなものなので、妙な階梯が意識されるようになるというデメリットは想定できます。ということで現時点では反対します。関係無いですが、管理者をもっと気軽に片手間でやってもいいものだという意識が広まったらいいですね。私が言うと怒られそうですが。tanuki_Z(sysopは偉くない) 2006年6月20日 (火) 07:05 (UTC)
なるほど、「偉い・偉くない」という話で捉えられてしまう恐れがあるわけですね……それは非常にまずいと思います。もしこれをやると「変な階層が一つ増えた」と捉えかねられないところで、結局導入してもデメリットの方が先行しそうですね。-- かえで 2006年6月21日 (水) 11:32 (UTC)
見習い制度はあまりメリットがないと思います。管理者に必要なのはすでにまとまった議論を元に対処することであると思うからです。で…かえでさんの推薦辞退を見て思ったのですが、管理者は必ず管理作業に時間をとって仕事をしなければならないものではありません。(もちろん時間と労力を使って作業されている方には敬意を表します。)「たまたまWikipediaで作業をしていて荒らしを発見したから対処を行った」で私は十分であると思っています。今必要なのは、(確かに削除依頼等で作業をしてくれるのもそうですが)人数を多くして常に誰かしらが緊急時に管理者権限行使をできるように層を厚くすることだと思います。その点で権限のない見習いでは一般利用者と差異がなくメリットがないのです。たね 2006年6月20日 (火) 07:24 (UTC)
見習い職を作るぐらいなら、議論の合意形成に向けて努力する方がより役立ちそうですね、なるほど納得です。「定常的に時間をとって仕事をしなければならない」という脅迫概念(?)は、今までの管理者立候補で行われて来た質疑そのものに由来するように思います。テンプレートの質問を引用すると【管理者に就任した場合、管理者権限を行使する仕事について、一日、あるいは一週間にどれくらいの時間を割くことが出来ると思われますか。】という問がありまして、これが新規立候補者にとって(心理的な)負担になりうる可能性を秘めているのかもしれません。 -- かえで 2006年6月21日 (水) 11:32 (UTC)

(インデント切って)ほとんど思いついたままの状態で案を提示させていただきましたが、さまざまな視点からご指摘頂き勉強になりました。害になりうる要素があり、かつメリットが見出せないとなると、この案を実施する理由は何もない事になりますので、本件は取り下げさせていただきたく思います。ただ考えるだけでなく、ここで実際にご意見をお聞きしてみた甲斐がありました。まずは本件に関しお付き合い頂き、どうもありがとうございます。また妙なことを考え付くかもしれませんが、その際にも変わらずご意見をいただけますと幸いです。 -- かえで 2006年6月21日 (水) 11:32 (UTC)

[編集] アカウント変更による活動期間の算出について

TEyさんへの投票において、Akinonijiさんの投票が「活動期間が一ヶ月に満たない」ことを理由に無効とされています。しかしAkinonijiさんは「秋の虹」として一ヶ月をゆうに上回る活動をしているわけで、有効票としてもよいのでは?と思います。このようなケースでは、ルール通り投票を無効にすべきでしょうか? それとも前のアカウントによる活動の期間を合算しても良いのでしょうか?--Bellcricket 2006年6月30日 (金) 03:06 (UTC)

今後のことを考えれば、新規に取得された場合は「残念ながら無効」とさせていただいたほうが、混乱がおきなくてよいと思います。--miya 2006年6月30日 (金) 03:38 (UTC)
これは無効でよいでしょう。一般的にはアカウントを変えた場合にその継続性を証明する手立てというのはほとんどないわけですからね。yhr 2006年7月2日 (日) 08:29 (UTC)

[編集] 2回目以降の立候補について

Wikipedia:管理者への立候補/十詩子 20060714の様に投票終了後まもなく再度立候補されるとほとんど荒らしですので、同じユーザが2回以上立候補する場合に制限を設ける必要があるかもしれませんね。(3ヶ月くらい?)--Goki 2006年7月15日 (土) 05:34 (UTC)

賛成です。今回は無効という事にしたほうがいいと思います--煌々 2006年7月15日 (土) 05:47 (UTC)
反対です。超法規的措置を繰り出すほどの案件とは思われません。再立候補制限規定は現状ではないのですから、粛々と処理すればよろしい。--Nekosuki600 2006年7月15日 (土) 06:03 (UTC)
まあ制限を設けるなら3ヶ月でいいとは思うんですが、落選者の再立候補ってそれほど実害があるもんだろうかという疑問もあります。--Nekosuki600 2006年7月15日 (土) 06:03 (UTC)
今回はルール通りにせざるを得ませんが、制限を設けること自体については良いかと思います。期間は前回の投票が終わってから3ヶ月程度、でしょうか。短期間で何度も立候補を繰り返され、その度にプロセスに付き合わされる面倒が省かれますね。--Bellcricket 2006年7月15日 (土) 06:12 (UTC)
制限を設けることには賛成です(期間も3ヶ月程度が妥当かと思います)が、後から設けた制限を過去にさかのぼって適用することには強く反対します。--B級へたれ 2006年7月15日 (土) 06:30 (UTC)
それほどにガチガチに決まりを作るのもどうかと思いますが・・・。所詮管理者就任見送りになった方はその直後立候補したところで、信任される確率はかなり低いでしょうし、相手にしなければ(いちいち賛否を表明しなければ)、自然失効するでしょうし。
それよりも将来、何かしらの不備(トラブル)により立候補しなおさなければならない状況が発生したとき、制限を設けてしまうと新たな問題が発生しませんか?--Trilingual 2006年7月15日 (土) 06:48 (UTC)
はい。放置しておけば当選することはないんで、いちいちつきあうという選択をした上でその選択について「つきあうのが面倒」というのは、ちょっとどうかなあと思います。

煌々氏によって「荒らしを撤去」として該当者の立候補が消去されていましたが、復帰しました。手続きを踏んで行われた立候補を荒らしと断定し撤去する権限など、誰にもありません。そういう超法規的措置の勝手な発動は慎んでもらいたい。まあ、通常の選挙でも、泡沫候補あたりについては「こいつの立候補は受理すんなよ」と言いたくなるケースは珍しくないわけですが、そういうのを粛々とかたづけるのも、こういう手続きのうちです。--Nekosuki600 2006年7月15日 (土) 07:09 (UTC)

「手続きを踏んで行われた」とありますが、いい加減な書式でコメント欄などもなく、前回もそういうことで一旦消去されたのでその前例に沿って消去しました。しかし、要約欄に荒らしと書き説明に欠けた事は反省します。--煌々 2006年7月15日 (土) 07:29 (UTC)
「つきあうのが面倒」について。確かに私一人の問題ならおっしゃる通り放置で済むのですが、当落の判定とか過去ログ化とか、他の誰か(特に管理者の方)がやらなければならない作業が発生するのはルール上避けられません。結局誰かが「面倒な役割」を背負い込む羽目になるわけで、ならば制度化して作業を最小限に留めることが必要なのでは、という考えです。--Bellcricket 2006年7月15日 (土) 07:46 (UTC)
自分もTrilingualさんの見解と同じです。--ECLIPSE 2006年8月25日 (金) 15:57 (UTC)

[編集] 移動履歴を編集回数としてカウントするか否か

言うまでも無く、記事の移動と言うのは記事上部の「編集」ではなく、その隣の隣にある「移動」という項をクリックして行う。つまり移動は編集には含まれないという事だ。

すると何が起こるのか?Wikipedia:管理者への立候補/利用者:たね 20060704において反対票を投じたIhsanan氏は 2006年7月4日 (火) 01:58 - 2006年7月4日 (火) 01:58 の通常名前空間の編集回数が4回となり[2]、投票資格を失うため反対票は無効となる。

そうなると、たね氏の得票は賛成:58、反対:19となり、信任が成立する。いかがだろうか?--220.105.145.51 2006年7月18日 (火) 07:06 (UTC)

2006年6月4日 (火) 01:58 - 2006年7月4日 (火) 01:58 の誤りですね。--水野白楓 2006年7月18日 (火) 07:35 (UTC)→追記:個人的にはリダイレクトが編集に入るなら、移動も入るような気もするのですが、判断が付きかねますし、また今回の投票に参加している立場から言っても無理に賛否を述べるべきではないと考えます。--水野白楓 2006年7月18日 (火) 08:02 (UTC)

Wikipedia:名前空間によると、ノートは「会話用名前空間」です。「記事名前空間」ではありませんね。するとカウントは4回、となります。--Bellcricket 2006年7月18日 (火) 07:58 (UTC)

追記…一応Wikipedia:編集合戦など、プロジェクト内には編集と移動は別という視点があるようですが、移動作業も編集同様記事内容に影響を与える作業なので、広い意味での「編集」とも解釈できるような…。私も投票行動をした者なので、今のところ判断は避けたいところですが。--Bellcricket 2006年7月18日 (火) 08:11 (UTC)

「移動は編集か?」ということは、客観的に判断するためにも今回の投票とは離して考えるべきです。立候補した人にとって、仮にここでの議論による微妙な判定で管理者になっても、後からことあるごとにいろいろ言われるかもしれないから不憫です。

そこで提案。「移動は編集か?」ということをこの場で投票で決めてはどうだろうか。その際の投票資格は、「今回の某氏の立候補への投票に参加していない」なおかつ「管理者への投票資格を有するユーザ」などとすると客観的かつ遺恨を残さないと思う。--211.9.148.154 2006年7月18日 (火) 08:15 (UTC)

賛成票を投じたAraisyohei氏も投票資格はないようですけど。賛成:57、反対:19では不信任ですね。--Gors 2006年7月18日 (火) 08:36 (UTC)

57対19なら、信任です。「投票期間が終了した時点で、10票以上かつ有効投票の内4分の3以上の賛成票を得た場合に候補者は信任されます」。念のため。--211.9.148.154 2006年7月18日 (火) 08:45 (UTC)
今丁度訂正しようかと思ってたとこでした。どうもスミマセン。丁度4分の3ですね。--Gors 2006年7月18日 (火) 08:46 (UTC)
「利用者の投稿記録」の画面で(標準)に切り替えると「標準記事名空間」だけへの投稿記事名が表示されますね。そこへはちゃんと問題となっている「移動編集」も表示されているので、編集回数不足とは云えないと思います。57票と20票で不信任だと考えます。蛇足ですが、こういう大事な問題を提起する時は匿名(IP)でなく信任投票資格のあるアカウント名で提起するのが礼節にかなっていると思いますが。--Sashisu 2006年7月18日 (火) 15:01 (UTC)
投稿履歴のURLクリックすりゃわかると思うけど、そんな事は百も承知で訊ねてるんだよね。なぜIPなのか、、、普段はアカウントを持たない閲覧専門家だから。--220.105.145.51 2006年7月18日 (火) 15:34 (UTC)
移動を行うと移動元と移動先の両方が投稿履歴に残るので、移動1回が編集2回としてカウントされることになります。さすがにこれはおかしいと個人的には思います。ともあれ議論の場所を移したほうがいいと思うのですがいかがでしょうか。標準名前空間の編集回数は削除依頼・投稿ブロック依頼・管理者への立候補など様々なところに影響するので、この節丸ごとサブページへ移すのが適当だと思うのですが。--端くれの錬金術師 2006年7月18日 (火) 16:08 (UTC)
個人的には移動やリダイレクトで投票要件をかろうじて満たすときは投票を棄権していますが、ともあれ議論の場を移した方がよいと私も思います。それと下手に確定した結果にさかのぼって適用すると混乱を招くことが多いのでたねさんの立候補とは分けて扱ったほうがよいのではないかと思います。幸い?というかなんというか、見送られたことは再立候補を妨げるわけでもないですしこの問題と終了した投票とを分けて考えること自体は可能と思います。tanuki_Z(sysopは偉くない) 2006年7月19日 (水) 08:30 (UTC)
本来であればRfAとは切り離して議論すべき事柄だと思います。しかし、たねさんのRfAはまだcloseされていませんし、この議論に決着がつかない限り票数が確定しないため、そちらに響いてしまうのは避けられないと思います。とりあえず、/移動履歴を編集回数としてカウントすることの是非あたりに移動させて、告知も出そうかと思います。--端くれの錬金術師 2006年7月19日 (水) 12:40 (UTC)
確かに、通常の編集だと1回なのに、移動は2回として数えられるのは変ですよね。--PiaCarrot 2006年7月19日 (水) 14:33 (UTC)
別に数えられているわけではないでしょう。今回こうやって議論されているのは、移動を編集1回と数える数えないによってIhsanan氏の投稿回数が5回未満になるからなのです。最初から移動が1回数えられると言うのならば、移動することによって投稿回数が2回数えられようが今回こんなに問題にはなってはいません。--Gors 2006年7月19日 (水) 14:52 (UTC)

そもそも直近の編集5回というあの方針はソックパペットによる多重投票防止を念頭においた方針ですよね。 Ihsanan氏がだれかのソックパペットの疑いがあるわけでもないようですからそんなに騒ぐこともないでしょう。--Snow steed 2006年7月19日 (水) 18:57 (UTC)  今後、移動が編集に含まれるかどうかなどの議論は、Wikipedia‐ノート:管理者への立候補でされてはどうでしょうか。--Snow steed 2006年7月19日 (水) 19:02 (UTC)


以上、井戸端より転記--端くれの錬金術師 2006年7月20日 (木) 17:00 (UTC)

[編集] 意見表明

移動履歴を編集回数としてカウントするか否かが投票資格の有無に影響するという問題が明らかとなりました。先行する井戸端での議論をこちらに転記しましたので、参照の上、ご意見をお願いします。--端くれの錬金術師 2006年7月20日 (木) 17:16 (UTC)

Toki-hoと申します。たねさんの投票時点では、明文化した規定がなかったため、通常名前空間の履歴にある「移動」も「編集」としてカウントするという判断は正しかったと思いますが、「移動」は移動もとの編集履歴、移動先の編集履歴として2回にカウントされることもあることから、通常の「編集」とは区別して考えるべきものだと思います。そこで、各投票資格においては「移動は編集に数えない」という明文化をするのがシンプルでよいと思うのですがいかがでしょうか。Toki-ho 2006年7月23日 (日) 00:40 (UTC)--(太字の部分追加Toki-ho 2006年7月25日 (火) 23:59 (UTC))
ページの保護や移動によって挿入される null-revision は普通の編集と要約以外で区別がつかないので、チェックが少し面倒になりますね。5とか50といった数字に意味があるわけではないので、多少の誤差には目をつぶって、単純に版の数で数えても構わないのではないでしょうか。--Brevam 2006年7月23日 (日) 06:42 (UTC)
プレビュー機能を使わず同じ記事を短時間に5回10回編集しても、単純に編集5回、編集10回とカウントされるほうがよほど問題だと思われます。それに比べたら1回の移動を2回と数えることなど、些細な問題ではないでしょうか。かといって、「それなら投票資格の基準を、編集した記事数にすべき」「記事数を基準にした場合、1つの記事に時間をかけて完成度の高い記事を書く人と、サブスタブを乱立させる人の間に不公平が生じるので、加筆したバイト数を基準に」「加筆バイト数が基準では、草取りの価値を認めていない」・・・・・といった議論は望みません。Brevamさんのご意見に同意します。5や50といった数字は、便宜的に設けられた基準に過ぎないと考えております。投票資格判定を複雑なものにしてチェックの手間を増やしても、それに見合うメリットがあるのかどうか大いに疑問です。--B級へたれ 2006年7月23日 (日) 08:17 (UTC)
御意見ありがとうございます。わたしも「規則はシンプルに」がよいと思うことに、かわりありません。しかしながら、この春(4月6日?)導入された「移動」の「編集履歴(「標準」名前空間)への記録」にともなって、それをもとに計算される投票資格についての議論が行われなかったことが、たねさんのケースのときに顕在化したのだと思うのです。たとえば、今回Electric goatさんのケースに投票しておられる2006xさんの場合も「移動」を「編集」として算入すれば、回数が足りますが、算入しなければ回数が足りないようです。管理者就任を、コンセンサスでなく、投票にしている以上、その投票の有効性を確保するために、投票資格の明確化は必要と思います。わたしは、今回は「移動を編集と数えない」という提案をしましたが、明確化さえなされれば、「移動を編集」と数えることも、「移動は編集でない」と数えることも、さしてかわりないと考えてはいます。しかし、明確化がなされない状態で、投票が行われ、判断する人によってどちらでもとれる状態で選挙結果がでてしまうことの危険性のほうが、コミュニティーへの信頼を損なうと考え上記の動議をいたしました。Toki-ho 2006年7月23日 (日) 09:28 (UTC)
(新しく節を作りました)移動を編集2回としてカウントしても誤差の範囲内であり些細な問題とのご意見ですが、移動を編集2回としてカウントしてしまうと極端な例ですが移動のみを行なえば本来必要とする回数の半分で資格を得ることになってしまいます。5や50といった回数についても過去ログにあるように議論の結果として決まったものであり、決して意味のない便宜的なものではないと思います。
ですのでチェックは多少面倒になりますが
  1. 移動は編集回数としてはカウントしない
  2. 移動は編集1回としてカウントする
のいずれかが適切であると考えます。--端くれの錬金術師 2006年7月23日 (日) 10:17 (UTC)


私は移動をカウントしない方が良いと思います。編集が記事を形作る行為である事に対し、移動では新たな形の記事が作られていないあたり、編集と移動を同質と見るのはどうか、と思います。…もちろん、「移動の作業は評価できない」と事では有りません。移動も大切な作業であります。--Bellcricket 2006年7月23日 (日) 12:39 (UTC)
Toki-hoです。すみません。お教え願いたいのですが、様々な方の投稿記録を見ていますと、「1回の移動で投稿記録2行分(2カウント)になる」場合と「1回の移動で投稿記録1行分(1カウント)になる」場合があるように思います。この違いはなんでしょうか。上で「『移動』は移動もとの編集履歴、移動先の編集履歴として2回にカウントされる」と書いたのですが、必ずしもそうではないみたいで、申し訳ありません。Toki-ho 2006年7月25日 (火) 00:20 (UTC)
移動跡地のリダイレクトが(即時)削除された場合、移動の差し戻しが行われた場合が考えられます。名前空間をまたいだ移動の場合(Wikipedia名前空間から標準名前空間へ、あるいはその逆)も標準名前空間に残る投稿記録は一回になるでしょうか。--Brevam 2006年7月25日 (火) 02:00 (UTC) 前者2つは投票時には条件を満たしていたのに、その後の削除で条件を満たさなくなった場合にどうするかという議論に似ている気がします。--Brevam 2006年7月25日 (火) 02:02 (UTC)
私は現在のSpecial:Contributionsの仕様からいけば、移動を勘定するのが穏当だと思います。移動を目で省くのはうまくいかないでしょう。まあスクリプトで数えてるよそんなのという話はあるかもしれませんが。
この際、"Special:Contribitionsから標準名前空間の編集数を取得した際に与えられる編集の数"と条件を再定義してはいかがですか。また似たような事態があった場合に、もめなくてすむ可能性は高いのじゃないでしょうか。
妥協策として。移動を含めないns:0の編集が50回以上、という方を満足させるには、閾値をあげたらいいんじゃないかと思います。100にあげる、でも移動はいれる、というのもひとつの解じゃないかな。--Aphaia 2006年7月25日 (火) 06:08 (UTC)
安易な閾値の変更は賢い方法だとは思えません。まともな方への影響が大きすぎます。--Goki 2006年7月28日 (金) 03:17 (UTC)

(インデント戻します)Toki-hoです。Brevamさん、お答えありがとうございます。7月23時点で「移動は(必ず)2回に数えられる」と誤認していましたこと、みなさまにお詫びします。申し訳ありません。Aphaiaさんもご意見ありがとうございます。閾値をあげる案、思いつきませんでした。ただ、当面の作業として、閾値云々にまで議論がすすむと、長引くおそれがあり、今は、「投票資格において『移動』を『編集』に数えるかどうかのコミュニティーの判断」をだすことに集中したいと存じます。で、端くれの錬金術師さんがだしてくださった選択肢の2番目「移動は編集1回としてカウントする」についてなのですが、これは「1回移動ボタンをおすことで記録に2回として残る移動は、1カウント」という意味でおっしゃったのだと思うのですが、「投稿記録に2回として残る移動」と「投稿記録に1回として残る移動」の見極めが難しく、現実的ではないように思うのです。そこで、この案をちょっと選択肢からはずさせていただいて、今でております案のメリットをこれまでの議論からまとめてみます。

1.移動を編集と数える
(メリット)「利用者の投稿記録」をみて投票資格を確認する際「どれが移動か、どれが編集か」という作業をしなくてもよい。
2.移動は編集として数えない
(メリット)「移動ボタン」を1回おすだけで、2カウントになる場合があり、不公平である。この不公平感をぬぐえる。<追記 Bellcricketさんのご意見はこれとはちょっとちがって、「『移動』はそもそも『編集』とは別物」と、いうものだと思います。>

私は、この議論をしているあいだに、「1」のほうが実質的かなと思うようになりました。つまり、「編集」だけであっても不公平感はともないます(下の議論御参照のこと)。投票資格を「数」で考えるときは、そういう不公平感を埒外におくしかないわけで、メディアウィキの改訂によって、「移動」が「投稿記録」にカウントされるようになったのなら、投票資格においては「利用者の投稿記録(標準空間)にあるものは、みんな『編集』と解釈する」という実質のほうをとったほうが、メリットが大きいのではないかと思うようになりました。みなさまは、いかがでしょうか。Toki-ho 2006年7月25日 (火) 23:59 (UTC)

Toki-hoさん、まとめて頂きありがとうございます。私も議論を見ているうち、1案の方が良いと思うようになりました。そうでなくとも最近の管理者信任投票では票数が増えてきて、投票権の有無を判断する手間がかかります。ここは少しでも手間を省けるというメリットを取った方が良いと思いました。一方Aphaiaさんの閾値を上げるという案もまた良い案だと思います。いずれ検討したい所です。--Bellcricket 2006年7月26日 (水) 01:20 (UTC)
Bellcricketさんご意見ありがとうございます。Aphaiaさんメタの情報ありがとうございます。この場での議論からは「投票資格においては『移動』は『編集』と数える」というコンセンサスができかけております。あと1週間ほど待ってこのコンセンサスを覆す有意の反対がなければ、このコンセンサスを尊重でよろしいでしょうか。Toki-ho 2006年7月29日 (土) 00:34 (UTC)
Toki-hoさん、とりまとめありがとうございます。改めて議論を追いまして、当初の意見を変更し1案を支持したいと思います。閾値を上げるという話は別途立ち上げましょうか。--端くれの錬金術師 2006年7月29日 (土) 16:56 (UTC)
インデントを戻します。移動は編集に数えるが、基本的に一回の移動は、「編集一回」と数えるというのがよいと思います。つい最近、エリザベス・キューブラー=ロスの記事を移動したところ、変なことが起こりました。わたしは個人的に、移動はあまり好まないので、どなたか移動してくされば幸いです、とノートに書きますと、早速移動された方がいるのですが、全角=ではなく、半角=の記事名に移動されているので、元に戻す移動を行い、更にそれを移動するという操作を行いました。(user:Star of Seaという作業用のアカウントで行いました)。履歴を見ると分かりますが、移動は二回しか行っていないのに、ノートも含めて、八回もの移動編集になっています。もう一つ、気づいたことは、実は、Maris stella で、「エリザベス・キューブラー=ロス」のリダイレクトページを作成していました。ところが、その編集履歴が消えています。これは確認できませんが、どうもリダイレクトがすでにある場所に移動すると、リダイレクトを造った履歴が消えるようです。こういうことから、移動は、ノートも一緒の場合で数が増えても、基本的に一回の移動は、編集一回と数えるのが妥当と思います。--Maris stella 2006年7月30日 (日) 16:47 (UTC)
端くれの錬金術師さん、ご賛同ありがとうございます。Maris stellaさん、具体例をあげてのご意見ありがとうございます。移動が「利用者の投稿記録欄」で2回に数えられる場合もあることについては、上で端くれの錬金術師さんがご指摘くださっていますのでご覧ください。さて、 Star of Seaさんの投稿記録を拝見しました。投票資格を数えるときは、ノートページを問題にしませんので、「名前空間: (標準)」にしてみてみますと、2006年7月29日 (土) 21:40の移動と、2006年7月29日 (土) 21:43 の移動が計上されています。2回の移動で4行ですね。 これはBrevamさんのお教えくださった、「移動跡地のリダイレクトが(即時)削除された場合、移動の差し戻しが行われた場合」がいまだなされていない状況でしょう。それで、選挙資格をはかる時点で、それがどうなっているのかはわからないのですが、ともかく、「この移動によるリダイレクトは削除済みであるかどうか」など細かい判断のいる作業をはぶいて、利用者の投稿記録を標準名前空間でみてそこにあるものの数(行数)で数えるほうが、実際的だと思うのですが、いかがでしょうか。Toki-ho 2006年7月30日 (日) 23:06 (UTC)
えっとMediaWikiの仕様変更で投稿履歴に加わるようになったのは移動だけではなく保護・保護解除も入るようになってますので同様に議論願います。管理者のなかには普段編集をほとんどせず主に管理業務をされている方もおり、5rdit/月を満たす際に大きな分かれ目となります。--Suisui 2006年7月31日 (月) 22:31 (UTC)
保護、保護解除もカウントする、でよろしいと思います。カウント時に便利なのはもちろん、管理業務を日々こなされている方が投票権無しでは、苦労が報われません。--Bellcricket 2006年8月1日 (火) 09:13 (UTC)
移動をカウントするのであれば保護・保護解除についてもカウントするべきと思います。先にToki-hoさんが提案された「特別:Contributionsにおいてnamespace:0で表示されるものすべてを編集回数としてカウントする」が一番わかりやすいかと。--端くれの錬金術師 2006年8月1日 (火) 09:58 (UTC)
わたしもBellcricketさん、端くれの錬金術師さんに賛成です。Toki-ho 2006年8月1日 (火) 12:08 (UTC)
意見を述べたまま、放置していまして申し訳ありません。個人的にはなお、移動は一回と数えるのが合理的だと考えていますが、編集回数のカウント上での実務での合理性からは、移動を二回または、一方が削除されているなどで、一回になっている場合でも、個別に、どれが移動の編集かというような区別をせずにカウントを行うのが、実際の作業上は合理的と思います。従って、「移動は編集に数える」「その編集数は、Toki-ho 氏が述べられているような方法が「実際的」である」として同意します。また、Suisui さんの提起も同意します。前置きが長いですが、結局、上の8月1日0958(UTC)での端くれの錬金術師さんの提案に賛同します。--Maris stella 2006年8月5日 (土) 17:40 (UTC)
Maris stellaさん、お早いお返事ありがとうございます。--端くれの錬金術師 2006年8月5日 (土) 17:57 (UTC)

(インデント戻します)みなさま、ご意見ありがとうございます。この場では「移動、保護、保護解除の履歴を含めて利用者の投稿記録において標準名前空間の編集として表示されるもの全てを編集回数としてカウントする」ということで合意が形成されたと判断してよろしいかと思います、つきましては、井戸端 (告知)に出した上で、一週間以内に異議が出ないようでしたら次の一文をWikipedia:管理者への立候補#投票資格へ追加したいと思います。

記事名前空間の編集回数は、移動、保護、保護解除などの履歴を含め、利用者の投稿記録において標準名前空間の編集として表示されるもの全てを数えるものとします。

--端くれの錬金術師 2006年8月5日 (土) 17:57 (UTC)


一週間経過しましたが異議が出ないようなので、上記の一文を追加致しました。--Bellcricket 2006年8月12日 (土) 23:16 (UTC)

ありがとうございました。田舎に帰る予定を考慮していませんでした。--端くれの錬金術師 2006年8月14日 (月) 07:24 (UTC)
追記を確認しました。Bellcricketさん、端くれの錬金術師さん、議論にご参加のみなさん、ありがとうございました。Toki-ho 2006年8月14日 (月) 08:09 (UTC)

[編集] その他

意見というわけではないのですが。

  • 編集を数える際、移動を含めるのは Usercontributions とその数字を使っている toolserver 上の editcount も同じです。候補者の編集回数表示には(おそらく)移動を含め、投票者のほうは含めないで数えるというのは、やや美しくないようにも思いました。
  • 開発者の意見/仕様としては「移動は編集に数えられる」そうで、9月投票開始の理事補選では移動を編集に数えます。閾値(400edits+)の変更は前回より行っていません。ご参考になれば。--Aphaia 2006年7月28日 (金) 11:17 (UTC)

[編集] 投票資格における編集の質

連続投稿するユーザーが、後をたちませんその場合や、編集合戦などによるリバートも、移動に伴う諸編集で追記の無い場合等を、編集回数に入れないのは同でしょう。具体的には、リバートを0。30分以内の連続投稿は編集回数関わらず1、移動に伴う諸編集は、見出だけを変える場合や、追記を伴わない場合は0、曖昧さ回避など、項目の分離は、回数項目数関わらず1、記事分割は、編集回数、記事統合が最低2回となるが、関連する記事分割、記事統合はまとめて1にするのはどうでしょう。三菱善次郎(zenjiro-mitsubishi)talk|action 2006年7月23日(日) 13:30(UTC)

三菱善次郎氏の仰ることはわかりますが、それをカウントするのは誰なんでしょうか?--Trilingual 2006年7月23日 (日) 14:03 (UTC)
最近のRfAでは投票総数が50を越えることも珍しくありませんが、それだけの利用者の投稿履歴をそのような条件に従って検証するのにどれだけの労力と時間が必要になるか考慮された上でのご提案でしょうか?あまりにも非現実的な案だと思います。--端くれの錬金術師 2006年7月23日 (日) 14:29 (UTC)
最終的に確認するのは常にビューロクラットになります。現実的にカウントすることを考慮してくださるのであればここでの議論はほぼ意味がなく、MediaWikiが履歴に表示するものをすべて編集としてカウントする以外に選択肢はありえません。現状何も考えずに1月で5、全体で50以上/1ヶ月以上をカウントするだけでも30票もあれば10分やそこらでは終わりませんのでまとまった時間も強い意志も必要ですし、実際かなり苦しい作業です。(実際に再確認で無効になったりすることもわりとよくあります。)ここで提起されている問題は曖昧すぎる定義なので無理と思われますが、うえのほうで行われている議論はある程度の自動化を前提とされていると思います。そうでなければその作業を長く続ける自信はありません。というわけでより現実的には移動や保護をカウントする前提で数値のほうをいじる、というのが簡単で実務的です。--Suisui 2006年7月31日 (月) 23:08 (UTC)

私の書いたのと同じく単なる皮肉でしょ。移動はカウントしないようにしようと提案する一方で、移動より何の役にも立たない編集はカウントするという歪んだ提案をしている人に対するね。例えば、この人はリダイレクトを一つ作るだけで4回編集し、投票権を獲得しています。移動よりも変な編集は沢山あるのですよ。端くれさんの編集もほとんどは、これに近いクオリティのものばかりかと思いますが、こんな編集はカウントされて、移動のカウントは減らすことにする。わざわざ手間をかけて、そんな歪んだ数え方で移動を別にしてカウントし、どれだけの益があるんですかね。--Yomihitosirazu 2006年7月23日 (日) 16:45 (UTC)

[編集] 管理者候補の無期限ブロック

Wikipedia:管理者への立候補/ゆっこ: 20060813において、候補者が既にブロックされているユーザのソックパペットとして、無期限ブロックとなりました。よって今後のスケジュール通り進めたところで、質問に対する回答もいただけず、また管理者に信任されたとしても管理者としての活動が難しいかと思われます。よって以下の提案をさせていただきます。

  1. 立候補時に、ソックパペットの疑義が申し立てられた場合、審議をストップする。疑義が晴れた場合、その時間より審議をスタートする
  2. 審議中に管理者候補が、ブロックされた場合その時点で不信任とし審議を終了する。
以上について、お願いいたします。Faso 2006年8月19日 (土) 01:03 (UTC)
1については、規則として成立した場合、意地悪く考えると<ある立候補者を気に入らない人間が「こいつは××の靴下だ」とデマを言い立てて審議を妨害する>というケースが想定されます。この点を回避するため、行動パターンの同一性を第三者が確認するなど適用基準を厳しくした方がいいでしょう。2については、審議期間中にブロックされるようなことをした時点で管理者として適性があるとはみなされない(誤認ブロックは別でしょうが)ので賛成です。--Charon 2006年8月19日 (土) 01:10 (UTC)
1ですが、管理者選出プロセスとSockpuppetの審議を同時進行させても別に問題はないと思います。審議の模様も含めて選出の参考になるかと。2.についても不信任というのはちょっと早急な気がします。それこそ審議停止でブロック明けを待つというので良いのではないでしょうか。もちろん、無期限ブロックなら選出プロセス自体をキャンセルということで。 -- NiKe 2006年8月19日 (土) 01:21 (UTC)

ご意見ありがとうございます。1の場合は、チェックユーザーに時間がどれだけ掛かるかによるかと思います。即時であれば良いのですが。また仰られるように、悪意ある疑義申し立てを複数回繰り返される可能性もありますので、審議は続行で良いかもしれません。 よってこのように変更させていただきます。

1. 立候補時に、ソックパペットの疑義が申し立てられた場合も、審議は続行する。

2ですが、ブロックされると言うのは、Wikipediaのルールに反しない限り無いわけですから、Charon氏と同様に考えます。ブロック期間が短期に終わるかは不明ですし、再度立候補もできるかと思います。また次の1点もご審議いただきたく

3. 立候補自体を削除依頼された場合は、審議そのものは続行し、削除が決定された時点でその立候補は無効となる

よろしくお願いいたします。Faso 2006年8月19日 (土) 02:18 (UTC)
1の修正版と3にはとくに異論はありません。ただ、このように条文として列挙するより、例えば「立候補自体は、形式が整っている限り基本的に中断はしない」というように、より包括的な規則にした方がいいと思いますね。具体例だともっと別の場面も考えられ煩雑になりそうな気がします。--Charon 2006年8月21日 (月) 11:48 (UTC)
3にちと異論が。結局Wikipedia:削除依頼/Wikipedia:管理者への立候補/Electric goat 20060715は存続になりましたが、もしこれが削除となっていた場合候補者に対する攻撃手段として他人が過去にした質問を使用し削除依頼で動議を無効にするという手法が横行したのではないでしょうか?(そのための多重アカウントも想定されたでしょうし)また、それ以外にも動議のページに外部転載で荒らし動議をつぶすということも考えられます。--PiaCarrot 2006年8月21日 (月) 14:01 (UTC)
1についてはともかく、2は管理者の裁量によるブロックを除外しておかないと管理者に拒否権を与えることになりますのでせめてそのようにするべきかと。個人的には3ヶ月以上なら自動解任とあわせて考えてブロック成立時点で無効にしても構わないと思いますが、それ以下なら別に停止にも無効にもせず継続して構わないのではと思っています。
3についてはあえてそうするメリットが少なくとも現状わからないのですが、詳しい説明をいただけませんか?tanuki_Z(sysopは偉くない) 2006年8月22日 (火) 05:43 (UTC)
まず包括であるより、論拠としてあげておいた方が審議が円滑に進むと思われることから、記載をしたほうが良いかと思います、前例を引くのも難しい方もいるでしょうし。2については、tanuki_Zさんのご意見を含みコミュニティの合議によるブロックに変更。3は、進行をするページが無くなるのに審議が続行は考えられ難いのではないかと思いますが(選挙自体の無効に近い類かと)、悪用も考えられるとの指摘はその通りかと思いますので、修正を加えてみました。
  1. 立候補時に、ソックパペットの疑義が申し立てられた場合も、審議は続行する。
  2. 審議中に管理者候補が、コミュニティの判断によりブロックされた場合は、その時点で不信任とし審議を終了する。
  3. 立候補ページを削除依頼された場合は、審議は続行する。また削除がなされた場合、整合性が取れる形で審議を復帰する。

よろしくお願いいたします。Faso 2006年8月23日 (水) 01:19 (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