まえし/進捗M2 の編集

*まえしへの応援メッセージ [#u65d65f6]
- 樹海！！！！！！！！！！！ -- [[かめい]] &new{2007-09-12 (水) 20:33:13};
- 樹海2.0！！！！！！！！！！！！！！！！！ -- [[ろぎ]] &new{2007-09-19 (水) 13:41:15};
- 樹海3.0！！！！！！！！！！！！！！！！！  -- [[&#26583;]] &new{2007-09-26 (水) 12:18:09};
- まえししししししししししししｓ -- [[かめい]] &new{2007-11-28 (水) 18:35:02};
- 11月はあと二日だぞ！！！！ -- [[かめい]] &new{2007-11-28 (水) 23:11:18};
- まえししししいｓｓ --  &new{2007-11-30 (金) 20:32:20};
- 12月に入りました．マイルストーンに従ってますか？ -- [[かめい]] &new{2007-12-01 (土) 18:42:57};
- もやし --  &new{2007-12-05 (水) 13:37:55};
- もやし2.0 --  &new{2007-12-05 (水) 13:38:42};
- もやし3.0 --  &new{2007-12-10 (月) 14:00:41};
- 萌やし --  &new{2007-12-12 (水) 15:06:24};
- もえし --  &new{2007-12-14 (金) 21:54:32};

#comment

*進捗報告PPT [#v66f67bf]
-2007/09/11 &ref(ゼミナールⅡ発表資料（α未満版）.ppt);　orz
-2007/07/11 &ref(進捗報告6.ppt);
-2007/06/27 &ref(進捗報告5.ppt);
-2007/02/07 &ref(中間報告.ppt);
-2007/01/31 &ref(進捗報告4.ppt);
-2007/01/23 &ref(進捗報告3.ppt);
-2007/01/18 &ref(進捗報告2.ppt);
-2007/01/09 &ref(進捗報告1.ppt);

**シミュレーション結果と今後の課題点 [#y2acbf20]
-モデルＧ&attachref(i_sampleG.png);
-モデルＩ&attachref(i_sampleI.png);
-シミュレーション結果&attachref(result.xls);~
-その他のモデル&attachref(model.zip);~

■指標の限界~
シミュレーションの結果，モデルＩの結果がもっともよいものとなった．(モデルＧ，Ｈ，Ｉは重み付きである分値が大きくなる)~
モデルＧとＩはともに上（黄色）のコミュニティから８回のレスをもらっていて，回数的には同じだけど，モデルＧのほうが一見バランスよく幅広い人と交流をしているから良さ気に見えてしまう
※要するに単純に重みをかけ合わせるという点に少し疑問点が見つかった．

直感に合わないのは，ＩのほうがＧと比べ，取得している情報がコミュニティの一部の人の声だと感じてしまうからだ

幅広い人との交流を重視するのであれば，重みを考えず実質的な交流人数を表す次数だけ見ればいい~
重みをどうしても考えたいのであれば，(恣意的な方法ではあるが)対処法は2通り考えられる

-1．特定の人物と何度も交流する場合，2回目以降のやりとりから中心性の値を下げていく~
例）　アンドマンαが次数中心性0.5のＡさんと3回やりとりした場合~
　1回目　0.5~
　2回目　0.25~
　3回目　0.125~
　合計　0.875　※今までの考え方だと0.5×3で1.5になる~

-2．重みはそのままで，異なる人との交流であれば，その分値を加算するような形にする(幅広い交流している点を評価するという意味で)~
例）　アンドマンαがＡ，Ｂ，Ｃさんの3人とやりとりした場合~
　1人目　Ａさんの次数中心性の値　Ｃ(Ａ)~
　2人目　Ｂさんの次数中心性の値　Ｃ(Ｂ)~
　3人目　Ｃさんの次数中心性の値　Ｃ(Ｃ)~
　合計　Ｃ(Ａ)＋Ｃ(Ｂ)＋Ｃ(Ｃ)＋2α　※今までの考え方だとＣ(Ａ)＋Ｃ(Ｂ)＋Ｃ(Ｃ)になる~

個人的には重み情報も重要な要素だと考えているので，単純に中心性を足し合わせていくのではなく，アンドマンの幅広い交流（2つのコミュニティの網羅率）を反映させる形にもっていったほうがいい気がする．~
※ここではうまく説明できないけど，情報取得にしても，それがコミュニティ全体の声なのかごく一部の人の声なのかといった網羅率として考えたい．それに網羅率として考えれば，正規化できるし値域も0〜1にすることができる

**疑問・問題点 [#zc0680df]
-そもそもコーディネータって？
>開発にも積極的に取り組んで,ユーザの意見にも常に耳を傾け支援するめちゃくちゃしんどい人？
>>この場合媒介先のネットワークにどれだけ次数をはっているかをカウントして調べるだけでいい(実際に自分も議論に加わっているわけだから,つながっている先の重みとかはあまり必要ない．むしろ重みを考えると変にややこしくなる)
>>個人的には,開発の第一線でバリバリがんばっている人というよりかは,Documentation作成とか事務的な役割を追っている人がコーディネータになっていくような印象がある．(実際にApacheでは,コーディネータの何人かがDocumentationProjectに参加している人だったし・・・)
>ネットワーク間を媒介するただの窓口(こんな意見をもらいましたよと単に伝達するだけ)になっている人？
>>この場合であれば，重みを考える必要がある．例えばネットワークA⇒Bの流れを考えたとき，Aでもらった意見をネットワークB内のノードNiが議論として取り上げているかは，Niの出次数を見れば何となく分かる(ような気がする)

-流れを考えたとき入・出次数で分けて考えることに意味はあるの？
>ネットワークA⇒Bの流れを考えたとき，コーディネータとつながっているネットワークB内のノードNiが問題提起(要求)を投げかけたと考えると，このNiを中心に議論が行われれば出次数だけでなく入次数も多くなるはず．　Input，OutputでなくAll(一度でも意見交流しとことのある人の数＝知り合いの数)で考えたほうがよいのでは？

-ネットワークの特徴によって適切なつながり方も変わってくるのでは？
>例えばApacheのDeveloperとUserのネットワークで考えた場合，コーディネータとして多くのユーザと関わりを持っている(多くのユーザを支援し，多くの声に耳を傾ける)ことが好ましく，Developerに対しては，影響力のある(問題解決を図る上で問題に対して直接の関係者でかつリーダーシップがありそうな人につながっている)ことが好ましいと考えられる．
>※極端なことを言えば，Linuxの開発ならエッジの数よりも開発リーダーで決定権のあるLinus Torvaldsにつながっているかどうかが重要になってくるだろうし・・・

-ぶっちゃけ入・出次数のバランスを見ればいいんじゃないのか？
>ただ，バランスの悪いノード(入次数多で出次数少のノードとか)もいるわけだから，これらをタイプ別に分類(入・出次数の多少で4つのタイプに分類)して役割みたいなものを考えてみてもいいかも
>次数のバランスからタイプ別に分類して，擬似的な役割みたいなもの(パーティション)を与えたときにネットワークがどう見えるのか？とかネットワークにおいてどのくらいの割合を占めているのかと見てみたら何か言えるのだろうか？

タイムスタンプを変更しない

#comment

直感に合わないのは，ＩのほうがＧと比べ，取得している情報がコミュニティの一部の人の声だと感じてしまうからだ

テキスト整形のルールを表示する