1.wikiのシステム自体が議論に不適について 2014-02-16 (日) 12:30:52
wikiのシステムは議論には不適である 2014-02-18 (火) 12:07:35
議論掲示板凍結について 2014-02-23 (日) 19:38:09
『ある程度、話し合いは(議論でなくとも)必要である』
『「厳格な議論」は不可能であっても最低限の議論となるものは切り離すことは出来ない』2014-02-24 (月) 13:19:33
議論と投票のどちらに重点を置くか 2014-02-24 (月) 13:19:33
「議論で案をいくつか出す」→「それらを調整して選択肢にする」→「投票」という流れが定着してる
「最低限の議論の後、投票重視で構わない」 2014-02-26 (水) 15:37:50
当議論で発せられた発言を追っていくと、私の発言は、wikiで議論が可能かどうかから始まり、最低限の議論の必要性が発覚した後、投票と議論のバランスについて発言していました。これらの発言は「wikiでの議論」というかなり根本的なものから徐々に議論ルールにまで展開しようとしていた意図がありました(ボトムアップ?でいいのだろうか)。しかし他の議論参加者は、具体案を提示し、そこから細かい部分を具体的に議論している発言がありました(トップダウン?でいいのだろうか)。即ち、根本的に我々の足並みが揃っていなかったことに原因があったみたいです。ではここで改めますが、ここからは後者の方向で進行するとします。既にもがちん氏による素案があるようなので、それを元に進めていきたいと思います(私に素案を提示してくれという意見があったがここでまた素案が増えるとややこしくなりそう)。とりあえず私の空気の読めなさで議論に足止めを食らわせてしまって申し訳ない。 -- 提起者? 2014-02-27 (木) 19:26:08
「議論期間が長い」という点と「コテハンの是非」 2014-02-27 (木) 19:33:02
投票期間
48時間で区切ると77%の票だけ採用され、23%は捨てられる計算になるね、大体。タイムラインは、2/18の駆け込みを無視すると、45.9%、31.6%、13.4%、8.8%、となる。ラス日でも8.8%有る 2014-02-28 (金) 11:09:26
2014-02-28 (金) 16:09:54まとめ
【議論が尽くされたであろう部分。】
・当wikiはネットという特性上まともな議論を行うのは難しい。しかし、事柄をきめる際、投票のみで行おうとするとその投票の選択肢が不完全なものになりうる為、投票のための最低限の議論が必要である。
・当wikiで完全な議論は特性上不可能なため、投票のための短期的・簡易的な議論を行いなるべく早く終了させるのが望ましい。
・ただし、投票内の選択肢等に不満がある場合を考え、常に投票選択肢の中に「まだ議論を続行するべきである(議論延長)」という投票選択肢を設ける。
【平行線であると考えられるもの。】
・議論には参加者や議論状況把握等、議論を円滑に進めるために議論で発現する際はコテハンを必ず付ける(賛成派)。
・コテハンは発言力の格差が生じる恐れがあり、また対人論証を生むおそれがあるためこれまでどおりコテハンを付ける必要はない(反対派)。
・投票は時間がかかり、労力もかかるため、投票前の議論で参加者がほぼ満場一致の状況ならばそこで事柄を決定するべきである(賛成派)。
・投票参加人数よりも議論参加人数の方が圧倒的に少数人数であり、その人数だけで物事を決定するのは問題である(反対派)。
コテハンについて 2014-03-02 (日) 15:02:48 以降集中的に議論される
編集履歴アリの人だけに限定した投票結果は不要 2014-03-02 (日) 16:03:45
【投票告知】 記名についての投票が開始されたことをご連絡申し上げる。
投票期間は金・土・日・月の丸4日間程度。投票者諸兄におかれてはよくよく熟慮の上で、今後の議論掲示板のため、最善の選択肢に、遺憾無き投票を行われることを願いたい。 -- もがちん(投票進行役)? 2014-03-21 (金) 00:14:51 New!
なお今回使用させて頂いた外部アンケートサイトcubequeryは、誰にでも扱える容易さはあるものの、(1).開始日時を設定できない、(2).終了日は指定できるものの、終了時刻が23:59:59固定 と言う、二つの難点があった。今後投票係を務められる可能性のある諸兄は、一応念頭においておいて頂けると幸い。ただ、voteでやると最低限でもエディタのマクロ超活用、できればプログラミング言語の1つくらいはできないと集計、と言うか不正投票検出が非常に大変なので(扶桑参照。ダブルチェックさえも要する)、外部サイトに頼ると言う方向性自体は良いと思う。問題は、どこが適切か、だ。 -- もがちん(投票進行役)? 2014-03-21 (金) 00:19:21 New!
あ、そうそう、問題点(1).は、urlを秘匿しておくことで一応フライング投票の回避は可能。・・・が、寝てても自動的に投票が始まった方がいいよねえ、ってそういう話w まあ次回何かあったら、係の人の方で色々探して考えてみて頂ければ。 -- もがちん(投票進行役)? 2014-03-21 (金) 00:28:29 New!
コテハンは任意。
ただしどの案も過半数に届かず。「投票をどうするか」で議論される。
調整期間を置くだけでは認知が不足しているという提案が出る。
認知度をどう上げるかの議論が始まる。一時お預かりに。
メニューバーや、表示方法等。
簡易投票で「議論の流れ」を議論することになる。
【提案】「進行者は個人的意見を言わない」というぃぃょぅ氏ルールをやめてはどうですか?
個人として意見を言うときは「ぃぃょぅ」とし、進行役として振る舞うときは「進行役ぃぃょぅ」とすれば個人的意見を言ってもいいと思います。
そもそも通常は提起者=進行者です。提起者は何らかの主張があるからこそ提起者になるのであって、提起した瞬間から個人としての見解を述べられないなんていうのはナンセンスです。また、ロボットのように意思を持たない進行役を買って出る人なんて(ぃぃょぅ氏以外)ほとんどいないと思われますので現実的ではありません(給料もらえるんならやりますけど)。
実際のところ「開発・建造のレシピリストについて 」の進行者は(ちょっと行き過ぎ感アリアリだけど)ぃぃょぅ氏とは対局的な立ち位置でやってますし、ちょっと考え方変えてみたらどうでしょうか? -- 2014-03-26 (水) 01:47:24
意見しやすい環境づくりをすべきという声が上がる
コメ欄直下に気軽に自由にコメントしてと追記
提案者が行方不明になったので、一時お預かりには移行せず。
コテハンの議論について
課題
1.投票係が決まるまでに1週間かかったこと。
立候補者が出るまでに3日程かかり、その立候補者に異議のあるものから対立する立候補者が出るか確認するまでに更に4日程要し、正式に投票係が決まるのが遅れた。
根本的な問題として議論参加者が自己の主張を放棄して、中立な立場である投票係に立候補する事自体がまず無いこと。
また、その議論に参加していない者にとっては投票係をやろうとする動機が薄いこと。
そもそもボランティアでやろうとする人が少ないこと。
2.認知があまりされておらず、何が議論されているか分からないという参加者が多かったこと
分からないから怖いという感情論がコメントされた(これ自体は悪いことではないが)
⇒これに関しては「議題一時お預かり」をコメ欄直下にし、タイトルの「議論ルール制定」の横に進行中の議題を追記することで、若干認知度を上げる応急処置をした。
更なる対処として、メニューバーへの告知方法が議題として追加された。
3.今回も投票係は叩かれた
外部から意見を取り入れる為、議論参加者が増えること。
おしりの決まっていない議論期間に対して、延長できるとはいえ投票開始日時が予定されている調整期間では議論が紛糾することが多いこと。
cubequeryに不備があったこと。
コテハン
本議論の最中にコテハンを付ける人が多かった。そのため結果としてコテハンを付けた場合の擬似的な議論が展開された。コテハンの有無による議論の進行に変化があったのは以下の点だ。
コテハンを付けることによって、DAを監視して行われる個人攻撃は無かった。
コテハン付きを一纏めにして否定するコメントがあった。
コテハンを付けている人がどういう考えを持っているのかが分かりやすく人物像を想像できた。
進行役の個人的な感想
進行役は白紙化の発案者が名前をつけていなかったのでいちいち発案者と会話出来ているか確認するためにDAを毎度使うのが面倒だった。発案者には「○○発案者」とコテハンを付けてもらいたい・・・。
進行役や投票係はきちんと役目を果たさなければならないが、現状の議論掲示板では非常に叩きが多く、役職者への保護が足りない、これでは誰も立候補してくれる人がいないのではないかと思う。
現に前投票係さんは叩かれて役職を降りたあと2度と立候補してはもらえなかった。
とりあえず、認知度をもう少し上げて、投票係に関する所を整備できれば割りとましになる気がする
提案を書く時は、賛同を得ようとする書き方が良いと思う。>議論参加者
何かの提案をするときは「~したいです。5名ほど賛同を得ましたら進行役・投票係にお願いしたいと思います。」
こんな風に書くと賛同者が得やすいと思う。
「~した方がいいんじゃない?」みたいな書き方だと賛成の表明を得るのは難しい。気がする
決選投票を行うべきか
要約
- 分科甲:決選投票を行うべきか
以下主な争点 -- 2014-07-03 (木) 21:03:17- Q1,首位選択肢が過半数未満だった場合、決選投票をするか否か(否の場合、首位選択肢を投票の結論とする) -- 2014-07-03 (木) 21:03:46
- Q2,同率首位があった場合、決選投票をするか否か(否の場合、現状維持議論継続とする) -- 2014-07-03 (木) 21:04:08
- ↑の方の意見を取り入れた以下の
決選投票を行うべきか改二
①決選投票はせず首位選択肢を投票の結果とする
②同率首位がいる場合は決選投票
③3度目の決選投票となった場合は投票前に3日議論期間を挟む
④決選投票における投票候補は具体的な内容のもののみとし、「議論継続」「投票無効」等の議論状態に関するものは含めない New!
⑤投票者に争点を理解してもらう為、一設問の選択肢数を減らすよう努力する
修正案を再提案します。 -- 2014-07-06 (日) 22:46:28
全文
- 分科甲:決選投票を行うべきか
以下主な争点 -- 2014-07-03 (木) 21:03:17- Q1,首位選択肢が過半数未満だった場合、決選投票をするか否か(否の場合、首位選択肢を投票の結論とする) -- 2014-07-03 (木) 21:03:46
- Q2,同率首位があった場合、決選投票をするか否か(否の場合、現状維持議論継続とする) -- 2014-07-03 (木) 21:04:08
- 4月の段階で案は出揃ってたので、特に異論がなければこんな感じで票決をしたら良いと思います。(上でも投票の予定と言われていますし) -- 2014-07-03 (木) 21:04:25
- 議論の中でできるだけ選択肢を少なくしてもらって、初めから決選投票ってのが分かりやすくてやり易いと思うなあ。艦種ごとの特徴の件もあるし。 -- 2014-07-03 (木) 22:33:46
- ケースバイケースとしか言いようがない。艦首ごとの特徴でもそれが問題になったが、争点はそこではなく、投票の正当性だった。 -- 2014-07-04 (金) 03:34:20
- 現状、特に争点も無く議論テンポの加速が望まれているので、『決選投票を行うべきか』について以下の結論を
決選投票を行うべきか提案
①決選投票はせず首位選択肢を投票の結果とする
②同率首位がいる場合は決選投票
③投票者に争点を理解してもらう為、一設問の選択肢数を減らすよう努力する
提案します。一晩置いて意見が無ければ決定という事で進行役さんの承認を望みます。又、争点が生じたようなら上記の予定通り、投票で決を取って早めに解決したいと思います。 -- 2014-07-04 (金) 12:29:09- 4月にも述べていたんですが、決選投票を前提にするなら先に考えておくべきことがありますよ。
各候補の得票数が全て同数だった場合にも決選投票にするんですか?
また、同率首位のみによる決選投票の結果が再び同数だった場合にはどうするんですか?等 -- 2014-07-04 (金) 23:22:54
- 4月にも述べていたんですが、決選投票を前提にするなら先に考えておくべきことがありますよ。
- ↑同率首位が出たなら②より再び決選投票との結論がでます。そもそも全体で100票もあれば同率首位になる確率は単純に考えて1割未満、投票毎に母集団にずれが生じる事も鑑みれば投票が永久に同率首位を算出し続ける可能性は考慮するに値しないと考えます。
が、確率が絶無というわけでもないので以下を
決選投票を行うべきか改
①決選投票はせず首位選択肢を投票の結果とする
②同率首位がいる場合は決選投票
③3度目の決選投票なった場合は投票前に3日議論期間を挟む New!
④投票者に争点を理解してもらう為、一設問の選択肢数を減らすよう努力する
再提案します。
又、進行役さん曰く「全ての事項は投票を通すことが前提になっています」との事なので、議論加速の為に意見募集と同時進行で『決選投票を行うべきか改』の是非をここで問いたいと思います。
『議論の流れ』で定義されている正規の手順ではありません。しかし投票方式が固まらないと、投票を前提とした他議題がまるで進行しないので手順省略は承知の上で投票場を開設しました。ご了承ください。
尚、この投票に参加した場合、投票管理人が投票者IPを総取りする事になります。ご注意ください。 -- 2014-07-05 (土) 14:24:20- 投票で決着が付かなければ、投票を最大3回繰り返す。それでも決着が付かなければ議論に戻る。ということですよね。ということは投票候補として「再議論」「議論継続」を含めることは不可という縛りが発生することになりませんか? -- 2014-07-06 (日) 01:26:14
- ↑些細な発生率の例外を補う為に、これ以上細目を増やす意味は薄いと思います。標本数100、母集団の賛:否=0.5:0.5、という条件でさえ二度の投票で同率となる確率は0.6334%。発生率を高めに見積もっても1/157未満の事象の処理を細々と定義してあげる必要は無いでしょう。
とはいえ、これ以上は議論が平行線になりそうなので進行役さんの裁定を待ちます。 -- 2014-07-06 (日) 12:34:09 - ↑些細な発生率の例外云々ではなく、明記されていない「投票候補に対する制約条件」があるのではないかと言っているのですが。
例えば「議論不足、再議論」が候補に入っていた場合、1回目で例え最下位だったとしても復活の目があるわけですよね。全候補が対等ではない投票になってしまっています。
これを防ぐためには3日間の再議論を諦めて最悪延々決選投票を繰り返すか、そもそも候補に入れさせないくらいしかないと思いますよ。ですが候補に入れさせないということについては提案では触れていませんよね。 -- 2014-07-06 (日) 19:09:23 - ↑なるほど。では具体的にどんな文面なら良いのでしょうか? 上記草案提出者は決選投票連続拮抗の部分に関して正直ど~でもい~かなと考えているので、↑様が具合案を提出してくれるならそれに乗りたいと思います。(多分、他の方も決選投票連続拮抗の部分に関して意見が無いようなので↑様が草案を出されれば高確率で決定稿になるかと思います) -- 2014-07-06 (日) 20:06:39
- 「決選投票における投票候補は具体的な内容のもののみとし、「議論継続」「投票無効」等の議論状態に関するものは含めない。」といった文面を追加すればいいんじゃないでしょうか。
除外対象については「現状維持」が微妙な気もするので、詳細については後で決定でもいいですが、ここであげた2つについては確実に除外としておかないと収拾付かなくなりかねません。 -- 2014-07-06 (日) 20:39:34
- ↑の方の意見を取り入れた以下の
決選投票を行うべきか改二
①決選投票はせず首位選択肢を投票の結果とする
②同率首位がいる場合は決選投票
③3度目の決選投票となった場合は投票前に3日議論期間を挟む
④決選投票における投票候補は具体的な内容のもののみとし、「議論継続」「投票無効」等の議論状態に関するものは含めない New!
⑤投票者に争点を理解してもらう為、一設問の選択肢数を減らすよう努力する
修正案を再提案します。 -- 2014-07-06 (日) 22:46:28
投票・議論の結果の適用時期
全文
- 分科乙:投票・議論の結果の適用時期
以下主な争点 -- 2014-07-03 (木) 21:04:44- Q1,この議論での適用時期
A:全決定は即時適用
B:票決は即時適用、議決は議論ルール全体が決まってから適用
C:議決は即時適用、票決は議論ルール全体が決まってから適用
D:全決定は議論ルール全体が決まってから適用 -- 2014-07-03 (木) 21:05:01 - Q2,他の議論での適用時期について
A:議論ルール全体が決まるまで非適用
B:既存の議論スレには非適用 -- 2014-07-03 (木) 21:05:25 - こちらも4月の段階で案が出揃っていました。Q2は非適用時期に関しての提案しかないので議論のテンポを上げる為に一旦棚上げ、Q1もわざわざ議論参加者間での適応時期をずらすのも面倒なので特に問題無ければ棚上げで良いと思いました。 -- 2014-07-03 (木) 21:05:47
- 議論ルール全体が決まるのは数年先になると思う。よって、Q1のDは実質的に「お前ら一生議論しとけ」なのでカットした方が良い。また、Q2はどちらを選択しようと「お前ら一生議論しとけ」なのでQ2もカット(他案件も自案件も適用時期は同じにしてQ1だけで問う)した方が良い。 -- 2014-07-03 (木) 23:43:51
- Q1はAでいい。テンポよく決めていかないと何も解決しないですよ? -- 2014-07-04 (金) 03:40:54
- 現状、特に争点も無く議論テンポの加速が望まれているので、『投票・議論の結果の適用時期』について以下の結論を
投票・議論の結果の適用時期提案
①ルール制定議論では全ての決定を即時適用する
②他の議論については考えない(カット,棚上げ)
提案します。一晩置いて意見が無ければ決定という事で進行役さんの承認を望みます。 -- 2014-07-04 (金) 12:20:44- 「【決定事項】かつ【有効】な事項」については他の議論に対しても即時適用で良いと思います。実際、有効な物は全て投票を通して決まっていますし。「【決定事項】であるが、未だ【無効】な事項」についてはこの議論内でのみ即時適用という形にするにしても、実は決定事項にするための手順の詳細は決まっておらず、全ての事項は投票を通すことが前提になっています。決定事項かつ無効に掲載した前例としては72時間反対意見が付かない場合のみです。この辺りの手順を投票で固めないと有効性が疑われます。 -- 進行役? 2014-07-04 (金) 16:21:39
- Q1,この議論での適用時期
投票サイトの比較
- 提案者による多重投票の惧れが艦種ごとの特徴の議論で話題になっていた気がする。あの議論が潰れた主因は提案者の宗教主張が大きかったけど、今後多重投票の惧れを衒いに投票にイチャモンが付く可能性がありそう。なので、話が飛ぶけど敢えて既存の投票案の得失を整理したいと思う。 -- 2014-07-01 (火) 07:32:15
- A【#vote構文】
利:①設置が一番楽 ②衆人環視可能なので多重投票耐性を持つ
害:①多重投票自体は誰でもできる ②監視労力が甚大 -- 2014-07-01 (火) 07:32:42 - B【CubeQuery】
利:①幅広い投票方式を提供 ②作成者以外の多重投票を自動で防ぐ
害:①作成者は二重投票が可能 ②作成者が投票者のIPを総取りする -- 2014-07-01 (火) 07:33:01- A【#vote構文】
上記同様なので割愛 - B【CubeQuery】
個体識別法はIPアドレスじゃないっぽい。周知の通り、作成者不正に対して脆弱な点が先の議論の火種となってしまった。投票者IPアドレスを作成者が総取り可能なシステムであり、この情報を作成者が利用しちゃったのも議論炎上の一因だったり。 - C【VoteFactory】
条件不明。何かの拍子に再投票が可能だったので、条件さえ整えば多重投票はできると思う。作成者不正耐性が高いから投票者不正耐性さえあれば最善なんですが。 - D【Mr.アンケート】
恐らくIPアドレスで判別。IPアドレスがコロコロ変わるe-mobileだと、接続→投票→切断→再接続‥‥‥‥の無限ループで投票の水増しができた。尚、これも作成者がIPアドレスを総取り可能。 - E【SurverMonkey】
これも条件不明。e-mobileの再接続では水増しできなかったのと、パソコン毎の投票数指定があったので、パソコンや携帯の製造番号とかを参考にしているのではと予想。アンケートに投票限界数(100だっけ?)がある事で忌諱されたが、アンケート自体を複数作れば問題無さそう。IPアドレス総取り可能。- 補足:削除後、投票権が復活した事を確認。 -- 木主? 2014-07-02 (水) 19:55:43
- F【アンケートツクレール】
これまた条件不明。作成者側が任意で二重投票の可否を操作できる点は脆弱。一方、IPアドレス総取りが不可能なのは好ましい印象。- 補足:IP識別でした。再接続無限投票を確認。 -- 木主? 2014-07-02 (水) 19:56:16
- G【人気ブログランキング】
恐らくIPアドレス判断。再接続ループで五重投票を検証済み。IPアドレス総取り等の作成者権限は少ない。 - H【Questant】
識別条件は不明。SurverMonkeyもそうだが個々の回答を分析する際に任意票の削除ができる。作成者不正全般に言える事だが、複数人の作成者が立つ事で悪意ある作成者の影響を抑える事ができるので、票の水増しが利かない分だけ任意票削除の方がましかも。後、サイトが重かった。- 補足:削除されても投票済みのまま。 -- 木主? 2014-07-02 (水) 19:56:47
- 各票決法の得失を表組みしてみるとこんな感じかなと。
評価ポイント A B C D E F G H 設置の容易性 ○ × × × × × × × 維持の容易性 × ○ ○ ○ ※4 ○ ○ ○ IP安全性 ※1 × ○ × × ○ ○ × 投票者不正への耐性 ※2 ※3 × × ○? ○? × ○? 作成者不正への耐性 ○ × ○ ○ ※5 × ○ ※5
※1:結局、不正監視の為にDiffAnalizerで公開の必要あり
※2:人力なので突破される恐れあり、IPアドレスを使うのでe-mobileに脆弱
※3:上記に複数投票の報告例あり
※4:票数制限の為にミラーアンケートを作る手間がある
※5:任意票の削除が恐らく可能、但し二重投票は無理
- A【#vote構文】
- A【#vote構文】
投票方式
要約
- 結局、どこかしらで関係者の善意良識を期待してしまいますね。なら簡潔明快にした以下案を
投票方式提案改三
①投票係がB案【CubeQuery】かH案【Questant】で単一投票場を開設する
②不信任とする理由が明白な場合のみ複数投票場を開設し不正リスクを抑える
③全投票場の投票割合の平均値を以て全体の投票結果とする
提案します。
後、進行役さんに質問です。最終的に票決するとの事ですが、投票場の開設や投票の進行等も進行役さんにお任せして良いのでしょうか? -- 2014-07-05 (土) 15:34:33- 賛成します。 -- 2014-07-05 (土) 19:38:26
- 賛成なんだけど、②について「投票開始前に」と加えるのはどうでしょうか?投票開始後に新たな投票場の設置は認めないという風にしなければ、いつまでも誰かがゴネる可能性があります。 -- 2014-07-05 (土) 19:40:06
- 賛成票を頂け有り難いのですが、下の方で不正耐性もありwiki内で完結する投票方式が登場したようなので、この案はしばし取り下げます。お騒がせいたしました、すみません。 -- 枝主? 2014-07-06 (日) 12:33:34
- 誰も言わないからあえて言ってみる。 Wikiwiki運営によって、SMS認証必須のコメントページが作れるようになったじゃん。それはどうかな?①携帯電話一台につき1IDしかできないし、②Diffでみんなが監視できるし、なにより③このWiki内で完結する。 -- 2014-07-05 (土) 21:43:24
- ごめん追記。現状Wikiwiki運営の作ったテストページしかないから詳細は分からないけど、コメント欄だけじゃなくてページ全体SMS認証必須にできるかもしれない。 あと、携帯電話たくさん持ってたらある程度不正出来るけど、自ずと限界があるから被害は限定的に抑えられると思う。携帯持ってない人は、っていうのは、記憶違いだったら申し訳ないけど、DMMアカウント作るときに携帯電話認証したと思うんだよね。だとすれば艦これやっている人は携帯があるってことになるから問題ないと思う。 -- 木主? 2014-07-05 (土) 21:51:08
- wikiのアンケートひとつに手間暇と個人情報を差し出すほどの価値は感じられない人が多いだろうし参加者は激減すると思うわ。 -- 2014-07-05 (土) 23:32:14
- 明るい展望ですね。SMS認証についてwikiwiki運営からの明るいお知らせありです。つまりwiki内完結の不正防止型の投票ができるという。 -- 2014-07-06 (日) 03:38:39
- 上で色々と投票方式についてグダグダ言っていた者ですが、s/頁が現状最善のようなので議論の投票にはs/頁を用いるという事で投票方式の結論としたいと考えます。今後は
①賛成レスポンスが多いようなら、テスト運用も兼ねてs/頁でs/頁投票への賛否を図る
②賛成を票決できたなら、進行役さんに決定事項として承認してもらう
という形の展望を考えています。 -- 2014-07-06 (日) 12:32:56- SMS認証の賛否を問う投票はCubeQueryで実施してください。SMS認証に抵抗があるひとは否の投票すらできなくなるからです。 -- 2014-07-06 (日) 13:34:17
- ↑の人が言っているように、この案の票決をとるならまだs/頁(←枝主がそう書くので以後これ)は使わないほうがいいかも。あと、投票とは別でテスト運用もしたほうがいいと思う。 -- 木主? 2014-07-06 (日) 17:51:20