Projects/ModuleOwnerPrediction の履歴(No.27) - PukiWiki

[ トップ ] [ 新規 | 一覧 | 検索 | 最終更新 | ヘルプ ]

モジュールオーナー予測†

メンバー†

山谷
まさおさん

ゴール†

モジュールオーナーを見極めるためのメトリクスを提案し，コミッター予測に勝つ

課題†

データの分布をちゃんとみる
モジュールオーナーが不足しているときの昇格しやすさの分析
Precisionを0.7あたりまでもっていく
変数をぬいてPrecisionが0.5であれば，それはそれで結果（どの変数をつかっても0.1くらいなのが問題）

研究計画†

〜4月13日：OSS開発者にメール
〜4月20日：メールの内容をもとにモジュールおよびモジュールオーナーの定義の再検討
〜4月27日：モジュールオーナーの昇格前の活動を分析
〜5月4日：モジュールオーナーの昇格前の活動を分析
〜5月11日：メトリクスの決定
〜5月18日：メトリクス計測スクリプトの作成
〜5月25日：スクリプトの実行およびデータの分布の確認
〜6月1日：実験
〜6月8日：追加実験（SS発表資料作成）
〜6月15日：考察および修論目次作成
〜6月22日：アプローチとデータセットの章執筆
〜6月29日：関連研究と結果と考察の章執筆
〜7月6日：修論v1作成
〜7月13日：修論の修正・発表資料v1作成
〜7月20日：修論の修正
〜7月27日：修論発表？修論提出？
〜8月3日：修論発表？
〜8月10日：修論発表？

資料†

データ置き場†

タイトル
- データ
- [添付]

SIGSE191(2016年3月14日)†

発表資料：sigse191.pptx

学会発表†

SIGSE191(2016年3月14日)†

質疑
- 実際のOSSプロジェクトにおけるモジュールオーナー（コミッター）の選出方法はどうしているのか？
- 過去の実績はフィルタリングに使えて，そこからモジュールオーナーになれる開発者を選出する際，予測をするのではなく，活動量や活動内容を可視化した方がいいのでは？（Expertise Browserの方が支援できるのでは？)
- モジュールオーナーの定義が現状では，コミット1回以上行った開発者だが，それはおかしいのでは？

議事録†

2016年4月14日†

議題
- 比較評価の方法は自分でモデルを複数作って行う

DONE
- 変更ファイルを取得
- メールは分析が終わってから
- 予定はたてたけど変わりそう

TODO
- WebKitプロジェクト以外のプロジェクトでの変更ファイルのリストアップをする（木曜日）
- コミット数の多い開発者がどのファイルをよく変更しているかをリストアップする（金曜日）
- 輪講資料作成（月曜日）
- 実験のシナリオをまとめる（火曜日）
- すべてのプロジェクトでモジュール分割方法を再検討する（水曜日）

STAY
- モジュールオーナーの不足状況と昇格の関係を分析する
- データで説明できない開発者の昇格前の活動をみる

2016年4月6日†

議題
- モジュールオーナーを必要としているかメールしてみてはどうか？
- スケジュールをまずたてましょう
- Developer Initiation and Social Interactions in OSSとたたかうのもあり
- モジュールオーナーに着目するという点は新規性があるからEMSE14と違いはある
- まずはごみをしっかりとって予測ができるようにならなければ
- モジュールオーナーの定義を再検討
- モジュールの分割方法を再検討
- 人をみるということは多様性しかないので，一つのモデルでうまくいくとは思わない
- モジュールごとに予測モデルが違うくてもおもしろい（UIはコメントが重要だけどCore部分はパッチが必要）

DONE
- SIGSEでの発表
- コミッター予測の論文みつけて読んだ
- データベース復元
- メールデータの取得

TODO
- 計画をしっかりたてる
- メールする文章を考える

STAY
- モジュールオーナーの不足状況と昇格の関係を分析する
- データで説明できない開発者の昇格前の活動をみる

2016年3月1日†

議題
- データで説明できない開発者の昇格前の活動をみる
- 現状ではパッチを一回でも投稿した開発者をいれて予測しているが，フィルターの仕方をデータの分布から判断する（5回できるべきでは？など）

DONE
- 不均衡データでの機械学習について調査
- アンダーサンプリングをして再実験
- SIGSE用スライド作成
- 各モジュールのコミット数およびパッチ投稿数計測スクリプトの作成

TODO
- モジュールオーナーの不足状況と昇格の関係を分析する
- SIGSEでの発表資料完成
- データで説明できない開発者の昇格前の活動をみる

SCHEDULE

2016年2月23日†

議題
- コミッターの分布をみる限りじゃ予測できなさそう
- データをもっと詳しくみてからフィルタリング等を考えるべき
- アンケートをとるのはデータをもっとみてから
- 予測はシミュレーションベースでやるべきでは？（Who is going to metntorみたいに）
- まずはモジュールオーナーが少ない時期と昇格の関係をみよう

TODO
- モジュールオーナーの不足状況と昇格の関係を分析する

作業日報†

2016年4月†

8日
- 予定
  - メールを送る開発者をリストアップする
  - メールの本文を考える
  - EMSEの論文を読む
- 実績
  - メールを送る開発者をリストアップする
  - メールの本文を考える

7日
- 予定
  - メールを送る開発者をリストアップする
  - メールの本文を考える
  - EMSEの論文を読む

6日
- 予定
  - ミーティング・予定たてる
- 実績
  - ミーティング・予定たてる

2016年3月†

31日
- 予定
  - モジュールオーナーをフィルタリング

30日
- 予定
  - モジュールオーナー昇格後の活動量を取得するスクリプトの作成

25日
- 予定
  - モジュールオーナーの定義の再検討

24日
- 実績
  - 壊れたDBの復元
- 予定
  - 壊れたDBの復元

18日
- 実績
  - 後輩の指導
- 予定
  - 後輩の指導

16日
- 実績
  - SIGSEの参加報告
- 予定
  - SIGSEの参加報告

14,15日
- 実績
  - SIGSEの参加
- 予定
  - SIGSEの参加

11日
- 実績
  - SIGSEの発表練習
- 予定
  - SIGSEの発表練習

10日
- 実績
  - SIGSEの発表練習
- 予定
  - SIGSEの発表練習

9日
- 実績
  - SIGSEでの発表セリフ決め
- 予定
  - SIGSEでの発表セリフ決め

8日
- 実績
  - SIGSEスライド修正
- 予定
  - SIGSEスライド修正

7日
- 実績
  - SIGSEスライド作成
- 予定
  - SIGSEスライド作成

4日
- 実績
- 予定
  - SIGSEスライド作成

3日
- 実績
  - SS投稿
- 予定
  - SS投稿

2日
- 実績
  - SSのグラフ修正
- 予定
  - SSのグラフ修正

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日
- 実績
  - 再実験（パッチを投稿したことない人の完全削除）
  - 最新の文献調査
- 予定
  - 再実験（パッチを投稿したことない人の完全削除）
  - 最新の文献調査