Projects/ModuleOwnerPrediction の履歴(No.39)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Projects/ModuleOwnerPrediction へ行く。
  • 1 (2016-02-15 (月) 11:38:38)
  • 2 (2016-02-18 (木) 11:19:01)
  • 3 (2016-02-19 (金) 11:13:08)
  • 4 (2016-02-22 (月) 12:27:37)
  • 5 (2016-02-23 (火) 05:42:52)
  • 6 (2016-02-24 (水) 01:23:42)
  • 7 (2016-02-26 (金) 02:04:52)
  • 8 (2016-02-26 (金) 10:03:01)
  • 9 (2016-02-29 (月) 01:57:14)
  • 10 (2016-03-01 (火) 01:53:36)
  • 11 (2016-03-01 (火) 04:25:24)
  • 12 (2016-03-02 (水) 02:36:06)
  • 13 (2016-03-03 (木) 08:35:57)
  • 14 (2016-03-07 (月) 04:39:35)
  • 15 (2016-03-07 (月) 09:45:34)
  • 16 (2016-03-13 (日) 21:12:38)
  • 17 (2016-03-22 (火) 07:59:55)
  • 18 (2016-03-25 (金) 02:21:55)
  • 19 (2016-03-30 (水) 01:56:45)
  • 20 (2016-04-06 (水) 02:03:28)
  • 21 (2016-04-06 (水) 06:27:31)
  • 22 (2016-04-06 (水) 10:37:44)
  • 23 (2016-04-07 (木) 01:10:20)
  • 24 (2016-04-08 (金) 01:53:58)
  • 25 (2016-04-08 (金) 07:31:14)
  • 26 (2016-04-11 (月) 08:10:18)
  • 27 (2016-04-14 (木) 03:48:44)
  • 28 (2016-04-15 (金) 02:08:15)
  • 29 (2016-04-15 (金) 09:07:49)
  • 30 (2016-04-18 (月) 07:24:10)
  • 31 (2016-04-20 (水) 18:08:05)
  • 32 (2016-04-21 (木) 02:54:44)
  • 33 (2016-04-25 (月) 02:49:42)
  • 34 (2016-04-27 (水) 09:41:53)
  • 35 (2016-05-11 (水) 10:02:12)
  • 36 (2016-05-19 (木) 01:16:59)
  • 37 (2016-05-26 (木) 02:19:59)
  • 38 (2016-05-26 (木) 04:43:00)
  • 39 (2016-06-01 (水) 00:34:43)
  • 40 (2016-06-10 (金) 03:50:44)
  • 41 (2016-06-14 (火) 10:11:20)
  • 42 (2016-06-15 (水) 01:14:12)
  • 43 (2016-06-24 (金) 06:03:46)
  • 44 (2016-07-01 (金) 04:46:18)
  • 45 (2016-07-11 (月) 07:48:03)
  • 46 (2016-07-19 (火) 06:57:57)
  • 47 (2016-07-20 (水) 05:38:49)
  • 48 (2016-07-27 (水) 01:49:08)
  • 49 (2016-08-05 (金) 01:04:12)
  • 50 (2016-08-05 (金) 09:40:29)
  • 51 (2016-08-10 (水) 02:12:53)
  • 52 (2016-08-31 (水) 00:24:16)

---

Projects

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

メンバー†

• 山谷
• まさおさん

ゴール†

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

課題†

• データの分布をちゃんとみる
• モジュールオーナーが不足しているときの昇格しやすさの分析
• 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回以上行った開発者だが，それはおかしいのでは？

メモ†

mysqlでのdump作成コマンド†

• mysqldump -u root -p --single-transaction --quick --ignore-table=DB.TABLE DB > filename.sql

議事録†

2016年6月1日†

• 議事録
• DONE
  • SSのスライド作成
  • リサーチクエスチョン考えた
• TODO
  • SS参加
  • Dont Touch my Code読む

2016年5月25日†

• 議事録
  • 評価するのは精度というよりどれくらい早くコミッターをみつけられたか
  • まずはリサーチクエスチョンをたてる
  • サニタイジングありなし，で比較
  • don't cannot などの抽出
  • コミッターからの評価とすべての開発者からの評価の比較
  • いろんな場合の実験をしていってみせればいい
  • 最低頻出回数はデータの分布をみて上位100単語を使えば50%は網羅できるとかにすべき
  • 1000件のレビューデータをランダムに取得する場合は，複数回ランダムにとってきたときに結果が変わらないことを示す．

• DONE
  • 3パターンでレビューごとの頻出単語抽出
  • 輪講資料作成
• TODO
  • コミッターとそうでない開発者が受けているコメント抽出
  • SSスライド作成

2016年5月18日†

• 議題
  • カテゴリ問題をどう解くか？
    • 1.ゲームをはずす
    • 2.対象カテゴリのみをつかう
    • 3.all
  • A Preliminary Analysis of Vocabulary in Mobile App User ReviewsにもあるようにvocabularyによってRatingがことなる
  • 5starをみられる言葉をもらってる人がどんな人かをみてみる
  • コミッターになった人とそうでない人がどんな言葉をもらっているor発信しているかをみてみる

• DONE
  • Androidアプリのレビューデータの取得と整形
  • BTS上での返信の特定方法を考えた

• TODO
  • センチメント分析やってみる
  • 5starをみられる言葉をもらってる人がどんな人かをみてみる
  • コミッターになった人とそうでない人がどんな言葉をもらっているor発信しているかをみてみる

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

2016年5月11日†

• 議題
  • コミッターからの評判をセンチメンタル分析して定量化してみては？

• DONE
  • モジュールオーナーを割り出してみる
  • モジュールオーナーの昇格前の活動を目視で分析する（途中）

• TODO
  • モジュールオーナーの昇格前の活動を目視で分析する

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

2016年4月28日†

• 議題

• DONE
  • すべてのプロジェクトでモジュール分割方法を再検討する
  • だれがモジュールオーナーにふさわしいのかを考える
  • Apacheのデータセットを増やす
  • モジュール分割方法からコンポーネント情報を逆引きして分割が正しそうか確かめる

• TODO
  • モジュールオーナーを割り出してみる
  • モジュールオーナーの昇格前の活動を目視で分析する

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

2016年4月21日†

• 議題

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

• TODO
  • だれがモジュールオーナーにふさわしいのかを考える（金曜日）
    • Expertise Browserなどをみて
  • Apacheのデータセットを増やす（月曜日）
  • モジュール分割方法からコンポーネント情報を逆引きして分割が正しそうか確かめる（火曜日）
  • モジュールオーナーを割り出してみる（水曜日）

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

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