研究ネタ・アイデア/塩漬けの編集

[[研究ネタ・アイデア]]

**富士の樹海プロジェクト（銀の弾丸プロジェクト） [#xcafcbc9]
>[[まえし]] (2007-07-01 (日) 21:53:16)~
~
すべてを1つの指標であらわすオールマイティ指標作成．~

//
- maetrics --  &new{2007-07-03 (火) 16:26:25};
- 何を表したいのか明確にするべきだと思います．樹海の中の灯台みたいな --  &new{2007-07-04 (水) 04:38:49};

#comment

**無題 [#o307e0b4]
> (2007-07-01 (日) 21:52:11)~
~
中心性指標の組み合わせによるコーディネーション能力の計測~

#comment

**コミュニティ形成の適切さとプロジェクト成功との関係を調べる [#b77df2ec]
> (2007-09-06 (木) 17:45:37)~
~
最初コミュニティは適当（機能単位？とか）に形成される．でも，それがベストな形であるかは分からないし，活動内容や活動そのものの変化に伴って適切なコミュニティの形・規模は変わっていくと思う．~
~
イカリングモデルとかで実際のコミュニティの活動を見たときに，ある2つのコミュニティが比較的密接な関係(共通出現する人が多い)だったり，単一コミュニティで内部が分離(いくつかのクラスタが存在)しているといったことがありえそうなので，コミュニティ形成(または規模)の適切さとプロジェクトの成功との関係を調べてみる~
~
以下のような結果になったらいいかなと・・・~
-成功プロジェクト~
--コミュニティの形成の仕方（または規模)が適切で内部分離していない（1つの大きなクラスタっぽくなってる）~
--コミュニティ間も疎な(共通出現する人が少ない)関係になっている（統合したほうがいいところが見当たらない）~
~
-うまくいっていないプロジェクト~
--コミュニティ内で内部分離(クラスタが多い)していて，無駄に規模が大きい~
（SNA班でも，HCIとか実空間SNS,SNAと分けているように，円滑な議論をするならそれに適した規模のほうがいいし，無駄に大きいと関係ない不要なメールまで受け取らないといけないから，関係のあるメールを見落としたり議論しにくそうな感じがする・・・）~
--コミュニティ間も疎であったり密であったりとバラバラ~
（2つのサブコミュニティを考えたとき，共通出現する人が多いならコーディネータとか要らない気がする．むしろ，1つのコミュニティにしてしまうことで，2つのコミュニティに参加していない少数派を取り込んでしまったほうが手っ取り早いと思う）

Apacheは前者(単一コミュ二ティで内部が分離しているようには見えないし，コミュニティ間も疎だったはず)~
Eclipseは単一コミュニティで内部が分離しているかは確認してないけど，2つのコミュニティにまたがって共通出現している人の数が一定(割合は知らないけど)という意味では，前者に近い~
それに対して，Netscapeは単一コミュニティ内で分離現象が見られるかは確認してないけど，コミュニティ間では疎だったり密だったりとバラツキがあったはず(2つのコミュ二ティに共通出現する人の数も一定じゃなかったし)~

別に複数のOSSコミュニティで比較しなくても，1つのコミュニティを対象に時期をずらして，開発サイクルとコミュニティの形・規模との関係を調べてみてもいいかも~
※コミュニティの規模が適切でないと開発が遅れるとかバグの発生頻度が高いとか・・・~
もし，そういった関係があるのであれば，やはりコミュニティそのものも固定的なものでなく，流動的に変化していく必要があるのではないかと思う．~

規模が大きくなるにつれコミュ二ティの現状把握(実際に参加している人でも漠然としか分からない)は難しくなるのは当然のことだし，モニタリングとかして常時コミュニティがどういう状況にあるかを把握できれば，サブコミュニティを立ち上げたほうがいいのかどうかの判断基準になると思った

#comment

**16階層モデル・3階層モデル [#b9703333]
> (2007-08-08 (水) 14:59:46)~
~
16階層：開発者コミュニティのMLすべて~
3階層：ユーザ，開発者，テスタ~

#comment

**(構造的)立場の近さから，重要人物を特定する [#z648b15d]
> (2007-08-02 (木) 02:38:56)~
~
実際の立場の近さではないという意味で大いに問題はあるけど，上層部でやりとりすることが多いコミュニティでは，中心性の値から(構造的)立場が近い場合のやりとりを重み付けすることで，上層部の人間を見つけ出してみてはどうかと思った~~
例）AさんBさんの中心性をC(A)，C(B)と表したとき~~
1回あたりのAさんとBさんのやりとりを　1/(|C(A)-C(B)|)　みたいな感じで表現する~~
こうすれば，(構造的)立場が近いもの同士のやりとりであれば重く重み付けされ特徴がでてきそうな感じがした．~~

※アンドマンを評価するメトリクスを考えている最中，試しに1/(|C(A)-C(B)|)で重み付けしてみたところ，JoshuaよりもRoweやColm，Nickの値が高くなった　ただこれは1回の重みが100近くあるからかなり問題がある

これに対して，Joshuaのように，ユーザの支援に注力している人を見つけるには(構造的)立場が遠い場合のやりとりを重く重み付けをすればいい~~
この場合，|C(A)-C(B)|みたいにして，差分が大きいほど重みを重くすればいい~

※|C(A)-C(B)|のままだといくら差があっても0.○程度なので，整数値になるように100×|C(A)-C(B)|で重み付けして試してみたところ，Joshuaがずば抜けて高く評価される結果になった

#comment

**共通の知人が多いとハッピーモデル [#rb498d54]
>[[まえし]] (2007-07-31 (火) 08:55:02)~
~
詳しくは書けないけど，一回の投稿内容の質の違いを推測するためのモデルがあったらいいかなと．~
~

#comment

**無題 [#d2f18132]
> (2007-07-01 (日) 21:52:00)~
~
Netscapeなどの，役割を明示的に与えられたOSS開発者とそうでない開発者の違いみたいなもの~
netscape (グループが細分化されている） vs. apache （MLの分類が大雑把）~
まえし仮説：グループの細分化により，他のグループへの関心・責任感が薄れる~
グループが細かく細分化されているeclipseも今後衰退をたどるのか？

#comment

**無題 [#db54835e]
> (2007-07-01 (日) 21:51:53)~
~
コーディネータのメッセージの解析~

#comment

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

[[研究ネタ・アイデア]]

//
- maetrics --  &new{2007-07-03 (火) 16:26:25};
- 何を表したいのか明確にするべきだと思います．樹海の中の灯台みたいな --  &new{2007-07-04 (水) 04:38:49};

#comment

**無題 [#o307e0b4]
> (2007-07-01 (日) 21:52:11)~
~
中心性指標の組み合わせによるコーディネーション能力の計測~

#comment

**16階層モデル・3階層モデル [#b9703333]
> (2007-08-08 (水) 14:59:46)~
~
16階層：開発者コミュニティのMLすべて~
3階層：ユーザ，開発者，テスタ~

#comment

**無題 [#db54835e]
> (2007-07-01 (日) 21:51:53)~
~
コーディネータのメッセージの解析~

#comment

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

研究ネタ・アイデア/塩漬け の編集

研究ネタ・アイデア/塩漬けの編集