モジュールオーナー予測†
メンバー†
- データの分布をちゃんとみる
- モジュールオーナーが不足しているときの昇格しやすさの分析
- Precisionを0.7あたりまでもっていく
- 変数をぬいてPrecisionが0.5であれば，それはそれで結果（どの変数をつかっても0.1くらいなのが問題）
SIGSE191(2016年3月14日)†
学会発表†
SIGSE191(2016年3月14日)†
- 質疑
- 実際のOSSプロジェクトにおけるモジュールオーナー（コミッター）の選出方法はどうしているのか？
- 過去の実績はフィルタリングに使えて，そこからモジュールオーナーになれる開発者を選出する際，予測をするのではなく，活動量や活動内容を可視化した方がいいのでは？（Expertise Browserの方が支援できるのでは？)
- モジュールオーナーの定義が現状では，コミット1回以上行った開発者だが，それはおかしいのでは？
議事録†
2016年4月6日†
- DONE
- SIGSEでの発表
- コミッター予測の論文みつけて読んだ
- データベース復元
- メールデータの取得
- TODO
- 計画をしっかりたてる
- モジュールオーナーの不足状況と昇格の関係を分析する
- データで説明できない開発者の昇格前の活動をみる
2016年3月1日†
- 議題
- データで説明できない開発者の昇格前の活動をみる
- 現状ではパッチを一回でも投稿した開発者をいれて予測しているが，フィルターの仕方をデータの分布から判断する（5回できるべきでは？など）
- DONE
- 不均衡データでの機械学習について調査
- アンダーサンプリングをして再実験
- SIGSE用スライド作成
- 各モジュールのコミット数およびパッチ投稿数計測スクリプトの作成
- TODO
- モジュールオーナーの不足状況と昇格の関係を分析する
- SIGSEでの発表資料完成
- データで説明できない開発者の昇格前の活動をみる
2016年2月23日†
- 議題
- コミッターの分布をみる限りじゃ予測できなさそう
- データをもっと詳しくみてからフィルタリング等を考えるべき
- アンケートをとるのはデータをもっとみてから
- 予測はシミュレーションベースでやるべきでは？（Who is going to metntorみたいに）
- まずはモジュールオーナーが少ない時期と昇格の関係をみよう
- TODO
- モジュールオーナーの不足状況と昇格の関係を分析する
作業日報†
2016年3月†
- 30日
- 予定
- モジュールオーナー昇格後の活動量を取得するスクリプトの作成
- 1日
- 実績
- ミーティングでこれからどうするか話し合う
- データのプロットをする
- 予定
- ミーティングでこれからどうするか話し合う
- データのプロットをする
2016年2月†
- 29日
- 実績
- SIGSEの発表資料作成
- 再実験（学習データとテストデータの数を合わせる）
- 予定
- SIGSEの発表資料作成
- 再実験（学習データとテストデータの数を合わせる）
- 26日
- 実績
- 各モジュールのコミット数およびパッチ投稿数の時系列プロット
- 予定
- 各モジュールのコミット数およびパッチ投稿数の時系列プロット
- 24日
- 実績
- 各モジュールのコミット数およびパッチ投稿数計測スクリプトの作成
- 予定
- 各モジュールのコミット数およびパッチ投稿数の時系列プロット
- 23日
- 実績
- ミーティングで話し合う
- 各モジュールのコミット数およびパッチ投稿数の時系列プロット（途中）
- 予定
- ミーティングで話し合う
- 各モジュールのコミット数およびパッチ投稿数の時系列プロット
- 22日
- 実績
- これからの研究計画をたてる
- ICSMEまでに何をするのか具体的に考える
- 予定
- これからの研究計画をたてる
- ICSMEまでに何をするのか具体的に考える
- 19日
- 実績
- 開発者の分布のプロットをする
- Who is Going to Mentor Newcomers in Open Source Projects?読む
- 予定
- Who is Going to Mentor Newcomers in Open Source Projects?読む
- 開発者の分布のプロットをする
- 18日
- 実績
- 再実験（パッチを投稿したことない人の完全削除）
- 最新の文献調査
- 予定
- 再実験（パッチを投稿したことない人の完全削除）
- 最新の文献調査
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
sigse191.pptx
