SNA_20090409 の履歴(No.1)

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

---

ミーティング議事録

---

• 日時: 2009年04月09日(木) 11:03
• 記録者: まつ本
• 次回：2009年04月17日(金) 11:00

スケジュール†

• DICOMO2009
  • 5/18 〆
• IWPSE2009
  • 5/23 IWPSEアブスト
  • 5/28 原稿
  • 8/24-25 発表
• 特集号
  • 4/13 GN研
  • 5/18 DICOMO

まつしん研究進捗†

• 特になし

伊原研究進捗†

• todo
  • 石田研究,今週中に担当部分の解析を終わらす
  • がくしん

• やってること
  • 1.石田研究
  • 2.StagE
    • 大平MTGを今日午後に予定

---

三つの研究

• 予測モデル
  • ジマーマンが似たようなことをやっている
    • 類似バグを探して、バグの滞留時間を予測
• バグ管理システム構築
  • おやすみ中
• 石田さんのコラボ
  • やってます

---

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

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

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

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

以下は先週まで

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

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

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

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

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

大平研究進捗†

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

• 5/15 (Fri) Mozillaの人が来る
  • 12:00~ ランチミーティング (紹介30分，議論30分)
  • 13:30~ ゼミナール

• MozillaMtgに向けて決めないといけないこと
  • 何をこちらから発表するか
  • 何を共同でやるか

みずき研究進捗†

• 細かい話
  • 細かいtodoイメージを作っておく
  • 前回に議事録を読んでくること

• Todo
  • なんのためにOpennessを発表するのか？ゴールは？何の議論をしたい？

• todo:コミュニケーションの支援システムの開発チームをつくる
• todo:何をどうを支援するか考える
• todo:返信のディレイ時間を基にシステムで支援する手法を提案する
  • 大平先生とミーティングをした
  • SNATech開発チームを作った
    • 心は分散開発のディレイを考慮してコミュニケーションを効率化したい
    • 時差とか
    • 出力イメージを考えた

• Openness研究
  • 日本語にしてへ投稿予定
  • 投稿先を決めないといけない．知識流通ネットワーク研究会とか？

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

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

小山研究進捗†

• Now 就活中...

• todo
  • 時差分析に向けて，分析の観点を考える
  • Mozilla？の開発者を対象に分析する
  • RubyのDevMLが開発者だけになってるか

• todo:パイソンのコアとノンコア開発者の区切りが分かるメディアを調べて一覧表を作製
  • 調査中

• todo:瀧原稿を読む
  • よんだ

• 山本疑問：遅延は実際にあるのか？
  • 「遅延」という考えが変，加速する余地がある
  • 明らかにしたいのは「問題点」ではなく，「改善点・課題」

• 対象プロジェクトの必要条件
  • mboxが取得可能
  • 規模大きめ，有名，ある程度地理的な分散がある・・・
  • コア，ノンコアの定義ができること
  • メーリングリスト上で役割を切れること．ユーザが入ってこないこと．開発者だけを拾えること
  • ドメインは言語系
  • 可能であれば
    • もう一段深い開発者の役割が明確である．たとえばコミット権限ある／なしを拾える
    • パッケージ単位のMLがある

• 対象プロジェクト確定
  • 言語系に決定（perl, php, ruby）
  • まずはruby

• コア・ノンコアって何よ
  • 山本研究のようなCommit権限の話なのか？
  • コア・ノンコアではなくてRole (main contributer, developer, ...) の問題？
  • コア・ノンコアよりもみたいのはroleでしょうね
  • コミット権限ある／なしくらいは拾いたいが，

• 分析対象のRoleはどこまでを広いたいのか？
  • ユーザは対象にしたくない．開発者以上の役割だけを拾いたい
  • あくまで開発支援

http://www.google.com/notebook/public/12501891660217506090/BDQmeDQoQ3uiSwIMk

• タイムゾーンの実験をしました
  • 課題
    • データを決めないといけない
    • どのような表を作るか明確にする
  • 実行可能な実験
    • 6時間ごとの4つくらいに区切って分析する？

ネタ†

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