![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
[[ミーティング議事録]] ---------- - 日時: 2009年04月2日(木) 11:00〜 - 記録者: 山本 - 次回：2009年04月9日(木) 11:00〜 **内容 [#y3dfb36d] ***WEB [#e2224b18] 締切：3月30日(月)まで~ 書けたら随時アップしろ by小山 -- コミュニケーションとコーディネーションの分析 --- 山本研究いれる - 山本 ：オープンコミュニティのオープン性に基づく分析 ***まつしん研究進捗 [#k42eae6a] - 特になし ***伊原研究進捗 [#h5ae569a] 三つの研究 - 予測モデル -- ジマーマンが似たようなことをやっている --- 類似バグを探して、バグの滞留時間を予測 - バグ管理システム構築 -- おやすみ中 - 石田さんのコラボ -- やってます ---- - バグ管理支援システム構築について -- 修正時間短縮に向けた論文をサーベイしないといけない - 予測モデルについて -- 角田さんの論文読みましたが難しい言葉が多い… --- 同じ手法が使えそう -- この研究の有用性を考えながら手を動かしてます -- バグ登録時の未修正バグ数を取得する際，FIXしていないバグの数も取得する 必要がある --- これまではFIXしているバグのみを取得していた --バグ登録時期前後のバグ報告数について ---「前後」の定義を考えないといけない - TODO -- (バグ管理支援システム構築)修正時間短縮に向けた論文をサーベイ -- (予測モデル)いろいろ - HP作成（伊原カテゴリー）について -- 作成したところまでを添付します→書けたらアップして，その旨をMLに流す ~ 以下は先週まで - ＤＩＣＯＭＯの準備 - 未対応時間予測モデル - 滞留時間予測モデル - 1章が不透明 -- 利用者が、いつ直されるかが分かるだけ（100日か1日） -- 開発者は、いつまでに、直さないとだめなのかなを知れる？ - モデルの作成後 -- 結果がでるのか？ -- その研究は本当に有用か？ - 直感的に考えた時に -- active developerの数（最近、修正活動を行っている人） -- バグの数 - カテゴリ変数を増やすと説明能力が減る - カテゴリはエクセルにめもった - TODO -タスク -- 5/18 DICOMO2009 -- IWPSE2009 --- 5/23 IWPSEアブスト --- 5/28 原稿 --- 5/?? 発表 -- 特集号 --- 4/13 GN研 --- 5/18 DICOMO *** 大平研究進捗 [#if8ce0a9] - まつしんにお願いした -- コーディネーターをいつ出現したかを観察した（ヒストグラム） --- 正統的周辺参加（LPP） --- 半年以内にコーディネータになる人 --- 半年後にコーディネータになる人 -- 現在保留 --- 小山さんに頼んだ事を思い出し中 *** みずき研究進捗 [#l4518995] - TODO -- コミュニケーションの支援システムの開発チームをつくる --- 何をどうを支援するか考える --- 返信のディレイ時間を基にシステムで支援する手法を提案する --- GUIなど -ドイツの研究について -- dumke先生のHPで若い人探してます - 会議 -- SIGSSとか -- IWPSE？ --- 5月23日アブスト〆切 ***小山研究進捗 [#wbe577bf] - TODO -- パイソンのコアとノンコア開発者の区切りが分かるメディアを調べて一覧表を作製 -- 瀧原稿を読む -- 時差分析に向けて，分析の観点を考える -- Mozilla？の開発者を対象に分析する http://www.google.com/notebook/public/12501891660217506090/BDQmeDQoQ3uiSwIMk - タイムゾーンの実験をしました -- 課題 --- データを決めないといけない --- どのような表を作るか明確にする -- 実行可能な実験 --- 6時間ごとの4つくらいに区切って分析する？ -- 瀧原稿を読む -- 時差分析に向けて，分析の観点を考える -- Mozilla？の開発者を対象に分析する ***ネタ [#t36e87ba] -- 知識とスキルを学びたい人が多いので，プログラム上にあるライブラリー数を表示してやるだけでもいいサポートになるかも
