SNA_20090326 の履歴(No.1)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• SNA_20090326 へ行く。
  • 1 (2009-03-26 (木) 09:21:00)

---

ミーティング議事録

---

• 日時: 2009年03月26日(木)　17:00〜
• 記録者: 小山

内容†

WEB†

締切：3月30日(月)まで
書けたら随時アップしろ by小山

• カテゴリー
  • 伊原カテゴリーを作る
  • ソーシャルネットワークを活用した知識共有支援
    • おおか修論
    • 過去の研究の写真などを貼る
    • 同上
  • コミュニケーションとコーディネーションの分析
    • 山本研究いれる

• 大平先生：コミュニティ媒介性のページ
• まつしん：コーディネータ
• かめい　：コミュニティの可視化、スケールフリー性
• 山本　　：オープンコミュニティのオープン性に基づく分析
• 小山　　：大規模複雑データ

まつしん研究進捗†

• 特になし

伊原研究進捗†

熱のため休み

• バグ管理支援システム構築について
  • 修正時間短縮に向けた論文をサーベイしないといけない

• 予測モデルについて
  • 角田さんの論文読みましたが難しい言葉が多い…
    • 同じ手法が使えそう
  • この研究の有用性を考えながら手を動かしてます
  • バグ登録時の未修正バグ数を取得する際，FIXしていないバグの数も取得する 必要がある
    • これまではFIXしているバグのみを取得していた
  • バグ登録時期前後のバグ報告数について
    • 「前後」の定義を考えないといけない

• TODO
  • (バグ管理支援システム構築)修正時間短縮に向けた論文をサーベイ
  • (予測モデル)いろいろ

• HP作成（伊原カテゴリー）について
  • 作成したところまでを添付します→書けたらアップして，その旨をMLに流す

以下は先週まで

• ＤＩＣＯＭＯの準備
• 未対応時間予測モデル
• 滞留時間予測モデル

• 1章が不透明
  • 利用者が、いつ直されるかが分かるだけ（100日か1日）
  • 開発者は、いつまでに、直さないとだめなのかなを知れる？

• モデルの作成後
  • 結果がでるのか？
  • その研究は本当に有用か？

• 直感的に考えた時に
  • active developerの数（最近、修正活動を行っている人）
  • バグの数

• カテゴリ変数を増やすと説明能力が減る
• カテゴリはエクセルにめもった

• TODO
  • つのださんのを読んでみましょう
• 過去TODO
  • 未対応時間が長くなる要因を洗い出す．(4/20までに)
    • 要因を考える必要あり
    • コントロールできる or できない，データで見える or 見えないを明確に．
  • 障害管理ツールを運用する．（今後継続してやる）

• タスク
  • 5/18 DICOMO2009
  • IWPSE2009
    • 5/23 IWPSEアブスト
    • 5/28 原稿
    • 5/?? 発表
  • 特集号
    • 4/13 GN研
    • 5/18 DICOMO

大平研究進捗†

• まつしんにお願いした
  • コーディネーターをいつ出現したかを観察した（ヒストグラム）
    • 正統的周辺参加（LPP）
    • 半年以内にコーディネータになる人
    • 半年後にコーディネータになる人
  • 現在保留
    • 小山さんに頼んだ事を思い出し中

みずき研究進捗†

本日，行方不明

以下は先週まで

• OSS診断指標 ストーリーを考えた wiki参照
  • https://se.naist.jp/wiki/sna/?mizuki_grad

• ばねモデルを作成する
• 返信のディレイ時間を基にシステムで支援する手法を提案する
• awareness
• team member毎に、作る
  • 非対面なので、感じれるように支援する

• TODO
  • 何をどうを支援するか考える

• ドイツの研究について
  • dumke先生のHPで若い人探してます

• 会議
  • SIGSSとか
  • IWPSE？
    • 5月23日アブスト〆切

小山研究進捗†

• タイムゾーンの扱いについて
  • 6時間ごとの4つくらいに区切って分析する？
  • 意味的に区切る？（アメリカ大陸，ヨーロッパ大陸など）？
• タイムゾーン別の参加者（開発者とユーザ？）の分布
  • アメリカ 40%
  • ドイツ 15%
  • hogehoge ??%
• 異なるタイムゾーン間のリプライ数の分布
  • アメリカ→ドイツ 10%
  • アメリカ→イギリス 7%
  • ドイツ→アメリカ5%
  • hogehoge ⇒ hogehoge ？%
• タイムゾーン別のメール送信時間の分布（時系列）
  • 瀧君のYahoo分析参照
• タイムゾーン固定のメール送信時間の分布（時系列）
  • 上に同じ．
  • 人口の分布と近いでしょう．
• 平均リプライ間隔
  • 平均と分散
• タイムゾーン別の平均リプライ間隔
  • 日本人同士の平均リプライ間隔など
  • 4X4マトリック
• タイムゾーン別にしない方法（散布図）←これいい！
  • 横軸：リプライ間隔
  • 縦軸：時差（GMT)
• 異なるタイムゾーン間での平均リプライ間隔
  • 統計量から上位数パターンをチョイス
  • アメリカ→ドイツ 平均３.3日
  • アメリカ→イギリス 平均 2.1日
  • ドイツ→アメリカ 平均 1.7日
  • hogehoge ⇒ hogehoge ？？日

• TODO
  • 時差分析に向けて，分析の観点を考える
  • Mozilla？の開発者を対象に分析する

ネタ†

• 知識とスキルを学びたい人が多いので，プログラム上にあるライブラリー数を表示してやるだけでもいいサポートになるかも