まえしへの応援メッセージ†


↑

進捗†

↑

ゼミナール発表†

気合でのりきる!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

↑

プログラムたち†

ろぎやまつしんが作ったプログラム

注意事項※

ファイルの命名規則は↓の通りです．***には年月(6桁)が入ります．命名規則に従っていない場合はプログラムは動作しません（きめうちなので）．

  • 開発者サブコミュニティ(略記:dev)　⇒　dev_***.net
  • ユーザサブコミュニティ(略記:user)　⇒　user_***.net
  • バグ報告者サブコミュニティ(略記:bug)　⇒　bug_***.net
  • 2つないし3つのサブコミュニティをマージしたもの(略記：merge)　⇒　merge_***.paj

分析に必要なデータ作成の大まかな流れ

  • 1．getRelationWithCluster.plでmboxからnetファイルを作成する．
    　　↓
  • 2．命名規則に従ってnetファイルをリネームする．(mboxから作成した段階では年月.netとなっているため)
    　　↓
  • 3．mergeNetworksByName.plで2つのサブコミュ二ティ(netファイル)をマージしてpajファイルを作成する．(3つのサブコミュニティをマージするときは伊原プログラムで)

↑は2つのサブコミュニティをマージするまでの工程．↓はコミュ二ティ媒介性をはかるための作業

  • 4．makePajekMacro4calculateDegreeCentrality.plをもとにPajekで中心性を計算するためのマクロファイルを作成する．(ノード重み付きコミュニティ媒介性で必要)
    　　↓
  • 5．Pajekでマクロファイルを読み込ませて中心性を計算する．　←　すぐに値が取れる．
    　　↓
  • 6．metricsWithNoWgt.pl，metricsWithEdgeWgt.pl，metricsWithNodeWgt.plを用いてそれぞれのコミュニティ媒介性を計算する．
    • NoWgtCB(重みなしコミュニティ媒介性)
    • EdgeWgtCB(エッジ重み付きコミュニティ媒介性)
    • NodeWgtCB(ノード重み付きコミュニティ媒介性)
↑

mboxからnetファイル(3ヶ月分)の作成†

filegetRelationWithCluster.pl　←　修正済

入力：mboxファイル

※3ヶ月分なら3つのmboxファイルが必要　e.g.) 200007 200008 200009

出力：netファイル

※↑の入力例だと200007.netというnetファイルができる

batファイルの例

  • perl getRelationWithCluster.pl 2000101 200102 200103
  • perl getRelationWithCluster.pl 2000102 200103 200104
    　　　　　・
    　　　　　・
    　　　　　・

修正・追加した点
1．mboxからメールアドレスを抽出するための条件の追加．　　e.g.)　 "名前 <メールアドレス　（名前）"　とかも取れるようにした
2．スパム対策の偽造（"@"が" at "になっている）部分の解除　←　特にGIMPの中期に多くある
3．↓のルールで同一人物を特定．(大文字は小文字に統一)

  • ルール1：メールアドレスが完全一致ならば，同一人物
  • ルール2：メールアドレスの@以前が一致　&&　From行にある名前が完全一致ならば，同一人物

4．ノード0問題の解決（たぶんf(^ ^;)）
5．自己ループの削除　(Pajekで処理してもよかったけどめんどかったのでプログラムで処理した)

↑

2つのnetファイルをマージするプログラム†

filemergeNetworksByName.pl

※このプログラムは特にいじっていない

入力：マージしたい2つのNetファイル

出力：Pajファイル(merge_***.paj)

batファイルの例

  • perl mergeNetworksByName.pl dev_200101.net user_200101.net
  • perl mergeNetworksByName.pl dev_200102.net user_200102.net
    　　　　　・
    　　　　　・
    　　　　　・
↑

中心性を計算するためのマクロファイル作成プログラム†

filemakePajekMacro4calculateDegreeCentrality.pl
filemakePajekMacro4calculateBetweennessCentrality.pl

※個人的に作ったので，他の人が使うときは編集して下さいm(_ _)m　(特にディレクトリ名とか)

使い方：perl makePajekMacro4calculateDegreeCentrality.pl ○○ △△ □□ ××

出力：次数中心性(ALL)を計算するためのマクロファイル

○○ = OSSコミュニティ名　e.g.)　apache,gimp,netscape など
△△ = サブコミュ二ティ名　e.g.)　dev，user, merge など
□□ = 期間(開始年月)　：　e.g.)　2000年7月からなら200007
×× = 期間(終了年月)　：　e.g.)　2007年5月で終了なら200705

↑

コミュニティ媒介性を計算するためのプログラム†

重みなしコミュニティ媒介性　：　filemetricsWithNoWgt.pl
エッジ重み付きコミュニティ媒介性　：　filemetricsWithEdgeWgt.pl
ノード重み付きコミュニティ媒介性　：　filemetricsWithNodeWgt.pl

※かなり頭の悪い作りなっているので要注意．
Partitionの割り当ては手動で(各プログラムの比較的上のほうに書いてある)，2番目，3番目の引数として与えたサブコミュニティ名に従って自分で編集すること．
e.g.) perl metricsWithNoWgt.pl merge_***.paj dev_***.net user_***.net
subCommunity_1(dev) = 1, subCommunity_2(user) = 2, andman = 3 なので

  • $subCommunity_1 = 1;
  • $subCommunity_2 = 2;
  • $andman = 3;

もし，dev_***.netとuser_***.netを入れ替えるなら，

  • $subCommunity_1 = 2;
  • $subCommunity_2 = 1;
  • $andman = 3;

※defaultでは，subCommunity_1 = 1(dev), subCommunity_2 = 2(user) になってる．

batファイルの例　※NoWgtとEdgeWgtの場合

  • perl metricsWithNoWgt.pl merge_200101.paj dev_200101.net user_200101.net
  • perl metricsWithNoWgt.pl merge_200102.paj dev_200102.net user_200102.net
    　　　　　・
    　　　　　・
    　　　　　・

batファイルの例　※NodeWgtの場合

  • perl metricsWithNodeWgt.pl merge_200101.paj dev_200101.net user_200101.net dev_200101.vec user_200101.vec
  • perl metricsWithNodeWgt.pl merge_200102.paj dev_200102.net user_200102.net dev_200102.vec user_200102.vec
    　　　　　・
    　　　　　・
    　　　　　・

※netファイル(subCommunity_1 subCommunity_2の順)の次に，vecファイル(subCommunity_1 subCommunity_2の順)を付け足す

↑

アンドマンのメール送信回数カウントプログラム(伊原研究用)†

filecountMailNum4Andman.pl

アンドマン同士のメッセージのやりとりが開発者コミュニティで行われたものか，ユーザコミュニティで行われたものかまで調べた上で，アンドマンのメール送信回数をカウントするプログラム

使い方：perl countMailNum4Andman.pl merge_***.paj subCommunity_1_***.net

出力：それぞれのサブコミュニティ参加者へのアンドマンのメール送信総数

e.g.)　andman⇒subCommunity_1の参加者へのメール送信総数
andman⇒subCommunity_2の参加者への送信総数
andman⇒subCommunity_1&2の参加者への送信総数

同様に，プログラムの350行目以降をコメントアウトすれば受信回数も分かる
ちょっと改良すればアンドマン個人個人の送信回数を求めることも可能．

↑

研究ネタ？†

提案指標(コミュニティ媒介性)で他にどんな使い方ができるか・・・
ノード重み付きコミュニティ媒介性 　ハブ的な人とつながっているとアンドマンの評価を高くする　⇒　ノード重み＝次数中心性
　コミュニティ内の仲介者（？)とつながっているとアンドマンの評価を高くする　⇒　ノード重み＝媒介中心性

エッジの張り方を変えれば様々な様々な視点から分析できる　はず

↑

メモ書き†

軸がブレるといかんのでメモ書きしておく

基本的な考え方
　コーディネータの重要性(能力)はコーディネータと関わりのあるノードから見積もる
　　　どれだけ頼られているのか？どれだけ重要な人と結びついているのか？

1ステップだけ見る理由
　コーディネータ自身が及ぼすことのできる範囲だから
　　2ステップになるとコーディネータとつながるノードの重要性(能力)に影響する　虎の威をかる狐？

■重みは不要！？
いろいろ考えてみたけど，重みの取り扱いが一番めんどい
正規化の方法もそうだけど，考えもなしに取り扱うには向かないものだと思う
※実際，重み付きモデルがあるにも関わらずあんまり使われてないし

回数が何を意味して，どの程度多ければいいのか判断できない
単純に重みを考えれば結果は変わると考えられるけど，その現象を説得できる自信がない

重みを考慮するなら，どうしても重みを考慮しなければならない理由を先に見つけてから取り扱ったほうがいいような気がする

■媒介中心性は敵ではない！？
いろいろと考えた結果，媒介中心性は敵ではなくむしろマエトリクスの基本となるモデルであるという結論に至った

マエトリクスは媒介中心性の進化版として考えられ，コミュニティ間の仲介者評価に特化したモデルではないかと考えられる
媒介中心性との大きな違いは，仲介の形態(コミュニティ内の仲介とコミュニティ間の中間を切り離して考えている)に着目しているという点
付け加えるなら，OSSコミュニティみたいにMLを用いて交流しているコミュニティ間の仲介者評価に特化した指標だといえるかもしれない
結果として媒介性と同じような推移をたどるのは当たり前のことだといえる
個人的にはΣ(中心性)×Σ（中心性）モデルが自分の思い描くコミュニティ間の仲介者(媒介性)評価のための指標の理想系に近い

■重みの正規化方法
シグモイド関数でも何でもいいけど，ノード間の重みNを無限大に発散させた場合に1に収束する数式を用いればいいだけのこと
そうすれば値域は[0，1)として表現できる
※つながっている人物全てと非常に多くのやりとりを行ったときに限りなく1に近づく

シグモイド関数の場合，値の増加とともに緩やかに増加していくイメージがあるけど，
個人的にはもう少し急勾配な感じになる関数がいい

重みの最大値で正規化すると値に開きがあった場合（例：1と1000とか），値の小さなものはほぼ0になり無意味なものしてカウントされてしまう恐れがある
むしろ，ある一定回数以上に達したらそれ以上はほぼ変化なしといったほうが個人的にはしっくりくる

※心理学とかじゃないけど，ある一定回数以上交流したらお互いの親密度が急激に高まるような現象がありそうな気がする．もしあるのであれば，それに見合った関数を使えばいいと思う



■提案モデルのいうバランスについて　※バランスの解釈

　●量的な意味でのバランスのよさ

　2つのコミュニティに対しての交流人数や投稿回数に偏りがなく参加しているかどうか

　●質的な意味でのバランスのよさ

　2つのコミュニティに対して，それぞれのコミュニティにおいて重要だと考えられる人(中心性の高い人)とつながっているかどうかという点から，それぞれのコミュニティにおけるアンドマンの重要性に偏りがあるかどうか（みたいな）

※質的なバランスは少しオーバーな解釈かもしれないけど，一方のコミュニティでは重要な人とつながっていても，もう一方では重要でない人(中心性の低い人)としかつながっていない場合，2つのコミュニティにとってアンドマンの重要さ(重要視のされ方？)に違いがあるとも考えられるのではないかという気がした．

提案モデルでは，つながっている人の重要さ(中心性の値)に着目しているから，こんなことも言えるんじゃないかなと思った．

↑

シミュレーション結果と今後の課題点†

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

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

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

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

↑

研究内容?†

コーディネータ能力をはかるメトリクス(重み付)を考える　※情報の伝達効率をはかる
アンドマン(©かめい)

↑

既存のメトリクス(調査中)†

↑

既存のメトリクス(未調査)†

↑

提案メトリクスのいいところ(今のところ・・・)†

(金光さんの本に紹介されているそれぞれの中心性では)単一ネットワーク内での個々のノードの状態を表すメトリクスが多いけど，複数のネットワークを対象としたメトリクス測定方法は提案されていない点

↑

提案メトリクスの導出手順†

※(A⇒Bの場合)ネットワークA内で多くの人から情報を受け取った(Inputが多い)ノードがコーディネータを介して,ネットワークB内において発言力がある(Outputが多い)ノードにどれだけ情報を伝達させ,ネットワークB内に情報を浸透・普及させているかを表すイメージ

※Nが多くなったときいったい何を調べてるのかよく分からない．これだとコミュニティ間の依存関係(コミュニティの結びつきの強さ)を見ているような感じがする．

↑

疑問・問題点†

↑

進捗報告PPT†

↑

その他†

自分の中でのイメージであり単なる妄想です f(^ ^;)

↑

正統的周辺参加の評価？†

着眼点：OSSコミュニティでは新規にユーザが参加し脱退していくというサイクルがめまぐるしい　（新陳代謝が激しい)

正統的周辺参加が実際に行われていることがコミュニティを持続させる(OSSプロジェクトで言えば成功に導く)要因であるならば，成功と失敗(?)においてその差が現れてくるはず．

(イノベーションプロセスの論文中で中心性分析を行った結果)中心性の値の変動の要因としてこのような点も影響を与えていると考えられる．（むしろ，議論の内容・質が異なっているということのほうが影響している気がするけど・・・）

正統的周辺参加が行われている・促進されると考えれる状況　

正統的周辺参加の状況(?)を評価するための仮説(正統的周辺参加が行われている・促進されると考えられる状況を以下に考えてみた)

・新規参加者がコミュニティ内で積極的参加(発言)している場合

・新規参加者に対してコミュニティの受け入れ体制(?)が整っている場合

⇒新規参加者がコミュニティ参加後,多くの人と関係を築いているのであればそれぞれの中心性は現状維持か悪くても若干低下するぐらい

これに対して，新規参加者が積極的に参加せず，受け入れ体制(?)が不十分な場合

⇒新規参加者の次数・近接性は低くなるためネットワーク全体の次数・近接性平均の低下率は大きい

⇒いろいろな人が話しかけないと近接性は低くなり，媒介性が高くなる

※この仮説を検証するためには，時系列で新規参加者数・脱退者数の割合や脱退者のもともとの中心性(そのネットワークにおいての影響力のある人物であったかどうか) を考慮しないといけないし，議論の内容によっても影響を受けるだろうから調べるのは結構めんどくさくなると思う．

※参加時期にもよるけど，新規参加者のコミュニティ平均継続期間は，最低，リリースのサイクル以上であることが好ましいような感じがした．(リリースのサイクル以下だと途中で仕事放棄しているような感じがする)

↑

構造的中心性と重み付き中心性の値の差分から何か調べる†

単に構造的に中心であるということと，重みを考慮した場合では違いが現れてもおかしくはない．(金光さんの本では，単に構造的なとらえ方をした場合と，重みを考慮した実社会の現象に近づけたとらえ方とでは違いがあることは既に証明されていると書いてあった)

※構造的に中心であるかどうかは，議論の場でよくしゃべってるけど実のない話をしている人でも中心性は高くなることを表しているが，重みを考慮した場合ではそうはならないことがある． 構造的中心性と重み付きの中心性で差異がないほど，議論を活性化させている人≒次数の高い人と考えらえれる．

それに対して，構造的中心性と重み付きの場合とで違いが顕著なほど，あまり議論が円滑に行われていない(議論が発散している)ような感じがした．(勝手な妄想　orz)

↑

コミュニティの規模や議論の内容によって適切(?)なネットワーク構造があるのでは？†

Apacheでは1つのML内で開発に関する議論を行うのに対して，NetscapeやEclipseの場合，複数のMLに分けて議論を行っている．

どちらが好ましいとかは分からないけど，議論の内容やコミュニティの規模によってはより議論を活性化させるコミュニティ形態というものがありそうな感じがした．

文系的な考え方だけど，複数のMLに分割した場合とそうでない場合では，参加者の主体性・積極性に影響を与えると思った．明示的に役割を与えることで責任の所在なり責任意識は与えられるけど，他のMLへの干渉(情報共有)は少なくなる感じがする． ※あまりいい例ではないけど，たとえば研究室内でごみ捨て係を決めると，ごみ捨て係でない人はごみが一杯であるかをあまり意識しなくなるようなイメージ

実際にNetscapeの場合では，同じ開発MLでありながら複数のMLに横断的に現れる人は少なく，ひどいときは0になっていた．もし，Eclipseで複数のMLに横断的に現れる人が継続的に現れているのであれば，それが成功(?)の要因とも考えら得れるのではないかと思った． ※個人的にはある程度関係のある仕事をする(意見交流があっておかししくない)コミュニティ同士は始めからひとまとめにしておいたほうがいいのではと思った．今回考えるネットワーク数がN(複数のMLに分割されて作業している場合)で，コミュニティ間の依存度を見て，統合・分割をするなどコミュニティ構造も状況によって変化してもいいのではと思った．

議論の内容とコミュニティ形態に関しては，例えば新規機能を考えるならより多くの声に耳を傾けたほうが言いし，モジュールやプラグインが多い場合，いくつかのサブネットワークに分けたほうがいい気がする．ソフトウェア開発におけるフェーズ分析じゃないけど，そんなの感じで結果が出たら面白いかなと・・・

↑

コミュニティの規模や成長過程とコーディネータの関係†

GIMPとApacheのコーディネータを見ていて思ったことだけど，コミュニティの規模や成長過程によって，コーディネータとしての働きが変わってくるのではと思った． GIMP，Apacheはともにコーディネータのバランスはよかったけど，どちらかというとGIMPは開発者寄りでApacheはユーザ寄りのコーディネータだった．

コミュニティとしてある程度成長して成熟し，プロダクト(作ったソフトウェア)の利用者数が多くなればなるほど，よりユーザの意見に耳を傾ける必要があると思う． それに対して，開発規模が小さく利用者数がそれほど少ない時期では開発に注力していて開発寄りのコーディネータであってもおかしくはない．

↑

OSSにおけるソフトウェアの品質評価(?)†

亀井さんが言ってらしたように，開発MLとコミットログ(?)から評価する Bugzillaに報告されたBugの重要度によって開発者ネットワーク内での活発度の違いみたいなものがありそう(重要なバグほどみんなで一丸になって解決に取り組むとか・・・)

人と人とのつながりだけでなく，コミュニティの生み出すプロダクトの質が調べられたら面白いかなと思った．

トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS