Projects/ModuleOwnerPrediction
の編集
https://floss-lab.org/pukiwiki/?Projects/ModuleOwnerPrediction
[
トップ
] [
編集
|
差分
|
履歴
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
(no template pages)
[[Projects]] *モジュールオーナー予測 [#r3740ddd] **メンバー [#wdc30119] -山谷 -まさおさん **ゴール [#t38f33d7] -モジュールオーナーを見極めるためのメトリクスを提案し，コミッター予測に勝つ **課題 [#ic625f3e] -データの分布をちゃんとみる -モジュールオーナーが不足しているときの昇格しやすさの分析 -Precisionを0.7あたりまでもっていく -変数をぬいてPrecisionが0.5であれば，それはそれで結果（どの変数をつかっても0.1くらいなのが問題） **修論執筆計画 [#qaa8f6ee] -〜8月3日：結果の章の執筆 -〜8月10日：アプローチ・実験の章の執筆 -〜8月17日：考察の章の執筆 -〜8月24日：v1完成 -〜8月31日：編集 **資料 [#e3a4903e] ***データ置き場 [#wbfd4443] -タイトル --データ --&attachref(); ***SIGSE191(2016年3月14日) [#r363ad90] -発表資料：&attachref(sigse191.pptx); **学会発表 [#o2d8b9b0] ***SIGSE191(2016年3月14日) [#l835901e] -質疑 --実際のOSSプロジェクトにおけるモジュールオーナー（コミッター）の選出方法はどうしているのか？ --過去の実績はフィルタリングに使えて，そこからモジュールオーナーになれる開発者を選出する際，予測をするのではなく，活動量や活動内容を可視化した方がいいのでは？（Expertise Browserの方が支援できるのでは？) --モジュールオーナーの定義が現状では，コミット1回以上行った開発者だが，それはおかしいのでは？ **メモ [#p731eff0] ***mysqlでのdump作成コマンド [#i9da5c11] -mysqldump -u root -p --single-transaction --quick --ignore-table=DB.TABLE DB > filename.sql ***研究ステップ [#u04b64a8] -ステップ1：データをクレンジングしてモジュールごとに予測できることを示す --データの分布を確認し，ごみ（活動量が少なく昇格しているモジュールオーナー）を除き，予測する --本来，修士の要件を満たすための分析をまずする -ステップ2：モジュールごとの特徴を考慮した分析 --モジュールごとにモジュールオーナーのなりやすさは異なるのではないか？ --例：変更が難しい（core部分などの）モジュールはパッチをたくさん投稿しないとオーナーになりにくく，UIなどのモジュールはコメントを少しすればオーナーになれる的な -ステップ3：評判を定量化した分析 --仮説：活動量よりも活動の質の方が重要ではないのか？ --評判（肯定的なコメントを受け取っている）が高い方がモジュールオーナーになりやすいのでは？ **議事録 [#t6202f6e] ***2016年9月8日 [#hb2e313e] -議事録 -DONE --修論の修正点改善のための再実験 -TODO --修論最終版の作成 ***2016年8月31日 [#hb2e313e] -議事録 -DONE --修論提出と発表 --修正点の表作成(&attachref(修正点と修正案.xlsx);) -TODO ***2016年8月10日 [#hb2e313e] -議事録 -DONE --研究発表会用の資料作成(&attachref(進捗報告201608010.pdf);) --2章書いた --閾値を変更した追加分析 --タイトル案の提示 ---モジュールごとの活動量を考慮したモジュールオーナー候補者予測 ---モジュールオーナーを特定するための予測モデルの構築 ---モジュールオーナー予測のための予測モデルの構築 ---不具合修正プロセスの改善に向けたモジュールオーナー候補者推薦 -TODO --執筆 --(依存関係を考慮した予測っていうやつやってみる) ***2016年8月5日 [#hb2e313e] -議事録 --OSS開発におけるいらん --3章いらん --2.3と2.4を一緒にして，「MOの不足問題と支援の必要性」or「MOの不足問題と既存の支援手法」 --そのあとに先行研究の問題点と本研究の着眼点を --アプローチにもっと伊原手法のくわしい説明を（なぜ伊原手法をとりこむのかなどを中心に） --とりあえずv0の作成を！ -DONE --予測がはずれた開発者の分析(&attachref(FalseNegative-FalsePositive.pdf);) --結果の章の執筆(&attachref(yy_thesis_main.pdf);) -TODO --研究発表会用の資料作成 --依存関係を考慮した予測っていうやつやってみる ***2016年7月27日 [#hb2e313e] -議事録 --２章なに言いたいかわからん --コミッター不足が引き起こす問題にプロセスの話いれたらいいかも --モジュールオーナーとコミッターを一緒に言うのは誤解を生みやすいのでやめたほうがいいかも --昇格プロセスの問題点は？ --2.4に候補者予測の必要性を定義 --コミッター候補者予測は２章へ --シンプルに書いてみたらいいのでは？ ---２章・目的 ---３章・先行研究 ---４章・アプローチ ---５章・実験 --データセットではなくデータセットの作成方法 ---データセット ---5.1対象プロジェクト ---5.2データセット作成方法 ---5.3基本統計量 --考察 ---最初に結果がどうかを言わないと ---使えるのか使えないのかを言った上で，false positiveとかの話を -DONE --修士論文執筆計画を立てる（目次構成も含めて） --輪講資料作成 --外れ値を除去した場合での予測 -TODO --予測がはずれた開発者の分析 --結果の章の執筆 ***2016年7月19日 [#hb2e313e] -議事録 --モジュールとは何かをしっかりと説明できるように --ロジスティック回帰分析の説明とかをしっかりとできるように --前のモデルと比較して今回の差分を強調 ---前回はRecallが高すぎて，全員をモジュールオーナーと判断していた ---今回は，予測すべきではない開発者を削減することで，精度がよくなった -DONE --予測をはずした開発者の分析 --フィルタリング方法を変えてやってみる --決定木の構築 -TODO --修士論文執筆計画を立てる（目次構成も含めて） --輪講資料作成 -- ***2016年7月11日 [#hb2e313e] -議事録 --オーナーは無視する --大事なのはコミット権限を持っていない開発者の中からモジュールを担当できそうな開発者をみつけること --いろいろパラメーターを変えてみてやってみる --モジュールの特徴を考える（複雑さ的な） -DONE --STEP1を完了する ---データの分布をみる ---ごみを除去して分布をみる ---ごみを除去したデータで予測してみる -TODO --予測をはずした開発者の分析 --フィルタリング方法を変えてやってみる ***2016年7月1日 [#hb2e313e] -議事録 --オーナーは無視する --大事なのはコミット権限を持っていない開発者の中からモジュールを担当できそうな開発者をみつけること --いろいろパラメーターを変えてみてやってみる --モジュールの特徴を考える（複雑さ的な） -DONE --技術的貢献メトリクス計測スクリプトの完成 --社会的貢献メトリクス計測スクリプトの作成 --ICIS発表練習および発表 -TODO --STEP1を完了する ---データの分布をみる ---ごみを除去して分布をみる ---ごみを除去したデータで予測してみる ***2016年6月24日 [#hb2e313e] -議事録 --オーナーは無視する --大事なのはコミット権限を持っていない開発者の中からモジュールを担当できそうな開発者をみつけること --いろいろパラメーターを変えてみてやってみる --モジュールの特徴を考える（複雑さ的な） -DONE --輪講資料作成 --TDMデータ作成（normal, 2gram, tf-idf） --コミッターとコミッターでない開発者が受けているコメント分析 --技術的貢献メトリクス計測スクリプトの作成(途中) -TODO --技術的貢献メトリクス計測スクリプトの完成 --社会的貢献メトリクス計測スクリプトの作成 --ICIS発表練習および発表 ***2016年6月14日 [#hb2e313e] -議事録 -DONE --小ゼミの発表資料作成 --コミッターとそうでない開発者が受けているコメント抽出 --2グラムのパターンをやってみた -TODO --輪講資料作成 --Android appのレビューデータでの評価実験 ***2016年6月10日 [#hb2e313e] -議事録 -DONE --SS参加 --Dont Touch my Code読む -TODO --小ゼミの発表資料作成 --コミッターとそうでない開発者が受けているコメント抽出 ***2016年6月1日 [#hb2e313e] -議事録 -DONE --SSのスライド作成 --リサーチクエスチョン考えた -TODO --SS参加 --Dont Touch my Code読む ***2016年5月25日 [#hb2e313e] -議事録 --評価するのは精度というよりどれくらい早くコミッターをみつけられたか --まずはリサーチクエスチョンをたてる --サニタイジングありなし，で比較 --don't cannot などの抽出 --コミッターからの評価とすべての開発者からの評価の比較 --いろんな場合の実験をしていってみせればいい --最低頻出回数はデータの分布をみて上位100単語を使えば50%は網羅できるとかにすべき --1000件のレビューデータをランダムに取得する場合は，複数回ランダムにとってきたときに結果が変わらないことを示す． -DONE --3パターンでレビューごとの頻出単語抽出 --輪講資料作成 -TODO --コミッターとそうでない開発者が受けているコメント抽出 --SSスライド作成 ***2016年5月18日 [#ld356afc] -議題 --カテゴリ問題をどう解くか？ ---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日 [#ld356afc] -議題 --コミッターからの評判をセンチメンタル分析して定量化してみては？ -DONE --モジュールオーナーを割り出してみる --モジュールオーナーの昇格前の活動を目視で分析する（途中） -TODO --モジュールオーナーの昇格前の活動を目視で分析する -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月28日 [#ld356afc] -議題 -DONE --すべてのプロジェクトでモジュール分割方法を再検討する --だれがモジュールオーナーにふさわしいのかを考える --Apacheのデータセットを増やす --モジュール分割方法からコンポーネント情報を逆引きして分割が正しそうか確かめる -TODO --モジュールオーナーを割り出してみる --モジュールオーナーの昇格前の活動を目視で分析する -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月21日 [#ld356afc] -議題 -DONE --WebKitプロジェクト以外のプロジェクトでの変更ファイルのリストアップをする（木曜日） --コミット数の多い開発者がどのファイルをよく変更しているかをリストアップする（金曜日） --輪講資料作成（月曜日） --実験のシナリオをまとめる（火曜日） --すべてのプロジェクトでモジュール分割方法を再検討する（水曜日） -TODO --だれがモジュールオーナーにふさわしいのかを考える（金曜日） ---Expertise Browserなどをみて --Apacheのデータセットを増やす（月曜日） --モジュール分割方法からコンポーネント情報を逆引きして分割が正しそうか確かめる（火曜日） --モジュールオーナーを割り出してみる（水曜日） -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月14日 [#ld356afc] -議題 --比較評価の方法は自分でモデルを複数作って行う -- -DONE --変更ファイルを取得 --メールは分析が終わってから --予定はたてたけど変わりそう -TODO --WebKitプロジェクト以外のプロジェクトでの変更ファイルのリストアップをする（木曜日） --コミット数の多い開発者がどのファイルをよく変更しているかをリストアップする（金曜日） --輪講資料作成（月曜日） --実験のシナリオをまとめる（火曜日） --すべてのプロジェクトでモジュール分割方法を再検討する（水曜日） -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月6日 [#ld356afc] -議題 --モジュールオーナーを必要としているかメールしてみてはどうか？ --スケジュールをまずたてましょう --Developer Initiation and Social Interactions in OSSとたたかうのもあり --モジュールオーナーに着目するという点は新規性があるからEMSE14と違いはある --まずはごみをしっかりとって予測ができるようにならなければ --モジュールオーナーの定義を再検討 --モジュールの分割方法を再検討 --人をみるということは多様性しかないので，一つのモデルでうまくいくとは思わない --モジュールごとに予測モデルが違うくてもおもしろい（UIはコメントが重要だけどCore部分はパッチが必要） -DONE --SIGSEでの発表 --コミッター予測の論文みつけて読んだ --データベース復元 --メールデータの取得 -TODO --計画をしっかりたてる --メールする文章を考える -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年3月1日 [#a6a37adf] -議題 --データで説明できない開発者の昇格前の活動をみる --現状ではパッチを一回でも投稿した開発者をいれて予測しているが，フィルターの仕方をデータの分布から判断する（5回できるべきでは？など） -DONE --不均衡データでの機械学習について調査 --アンダーサンプリングをして再実験 --SIGSE用スライド作成 --各モジュールのコミット数およびパッチ投稿数計測スクリプトの作成 -TODO --モジュールオーナーの不足状況と昇格の関係を分析する --SIGSEでの発表資料完成 --データで説明できない開発者の昇格前の活動をみる -SCHEDULE ***2016年2月23日 [#a6a37adf] -議題 --コミッターの分布をみる限りじゃ予測できなさそう --データをもっと詳しくみてからフィルタリング等を考えるべき --アンケートをとるのはデータをもっとみてから --予測はシミュレーションベースでやるべきでは？（Who is going to metntorみたいに） --まずはモジュールオーナーが少ない時期と昇格の関係をみよう -TODO --モジュールオーナーの不足状況と昇格の関係を分析する **作業日報 [#ke425ed4] ***2016年4月 [#mf7c2c26] -8日 --予定 ---メールを送る開発者をリストアップする ---メールの本文を考える ---EMSEの論文を読む --実績 ---メールを送る開発者をリストアップする ---メールの本文を考える -7日 --予定 ---メールを送る開発者をリストアップする ---メールの本文を考える ---EMSEの論文を読む -6日 --予定 ---ミーティング・予定たてる --実績 ---ミーティング・予定たてる ***2016年3月 [#mf7c2c26] -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月 [#mf7c2c26] -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日 --実績 ---再実験（パッチを投稿したことない人の完全削除） ---最新の文献調査 --予定 ---再実験（パッチを投稿したことない人の完全削除） ---最新の文献調査
タイムスタンプを変更しない
[[Projects]] *モジュールオーナー予測 [#r3740ddd] **メンバー [#wdc30119] -山谷 -まさおさん **ゴール [#t38f33d7] -モジュールオーナーを見極めるためのメトリクスを提案し，コミッター予測に勝つ **課題 [#ic625f3e] -データの分布をちゃんとみる -モジュールオーナーが不足しているときの昇格しやすさの分析 -Precisionを0.7あたりまでもっていく -変数をぬいてPrecisionが0.5であれば，それはそれで結果（どの変数をつかっても0.1くらいなのが問題） **修論執筆計画 [#qaa8f6ee] -〜8月3日：結果の章の執筆 -〜8月10日：アプローチ・実験の章の執筆 -〜8月17日：考察の章の執筆 -〜8月24日：v1完成 -〜8月31日：編集 **資料 [#e3a4903e] ***データ置き場 [#wbfd4443] -タイトル --データ --&attachref(); ***SIGSE191(2016年3月14日) [#r363ad90] -発表資料：&attachref(sigse191.pptx); **学会発表 [#o2d8b9b0] ***SIGSE191(2016年3月14日) [#l835901e] -質疑 --実際のOSSプロジェクトにおけるモジュールオーナー（コミッター）の選出方法はどうしているのか？ --過去の実績はフィルタリングに使えて，そこからモジュールオーナーになれる開発者を選出する際，予測をするのではなく，活動量や活動内容を可視化した方がいいのでは？（Expertise Browserの方が支援できるのでは？) --モジュールオーナーの定義が現状では，コミット1回以上行った開発者だが，それはおかしいのでは？ **メモ [#p731eff0] ***mysqlでのdump作成コマンド [#i9da5c11] -mysqldump -u root -p --single-transaction --quick --ignore-table=DB.TABLE DB > filename.sql ***研究ステップ [#u04b64a8] -ステップ1：データをクレンジングしてモジュールごとに予測できることを示す --データの分布を確認し，ごみ（活動量が少なく昇格しているモジュールオーナー）を除き，予測する --本来，修士の要件を満たすための分析をまずする -ステップ2：モジュールごとの特徴を考慮した分析 --モジュールごとにモジュールオーナーのなりやすさは異なるのではないか？ --例：変更が難しい（core部分などの）モジュールはパッチをたくさん投稿しないとオーナーになりにくく，UIなどのモジュールはコメントを少しすればオーナーになれる的な -ステップ3：評判を定量化した分析 --仮説：活動量よりも活動の質の方が重要ではないのか？ --評判（肯定的なコメントを受け取っている）が高い方がモジュールオーナーになりやすいのでは？ **議事録 [#t6202f6e] ***2016年9月8日 [#hb2e313e] -議事録 -DONE --修論の修正点改善のための再実験 -TODO --修論最終版の作成 ***2016年8月31日 [#hb2e313e] -議事録 -DONE --修論提出と発表 --修正点の表作成(&attachref(修正点と修正案.xlsx);) -TODO ***2016年8月10日 [#hb2e313e] -議事録 -DONE --研究発表会用の資料作成(&attachref(進捗報告201608010.pdf);) --2章書いた --閾値を変更した追加分析 --タイトル案の提示 ---モジュールごとの活動量を考慮したモジュールオーナー候補者予測 ---モジュールオーナーを特定するための予測モデルの構築 ---モジュールオーナー予測のための予測モデルの構築 ---不具合修正プロセスの改善に向けたモジュールオーナー候補者推薦 -TODO --執筆 --(依存関係を考慮した予測っていうやつやってみる) ***2016年8月5日 [#hb2e313e] -議事録 --OSS開発におけるいらん --3章いらん --2.3と2.4を一緒にして，「MOの不足問題と支援の必要性」or「MOの不足問題と既存の支援手法」 --そのあとに先行研究の問題点と本研究の着眼点を --アプローチにもっと伊原手法のくわしい説明を（なぜ伊原手法をとりこむのかなどを中心に） --とりあえずv0の作成を！ -DONE --予測がはずれた開発者の分析(&attachref(FalseNegative-FalsePositive.pdf);) --結果の章の執筆(&attachref(yy_thesis_main.pdf);) -TODO --研究発表会用の資料作成 --依存関係を考慮した予測っていうやつやってみる ***2016年7月27日 [#hb2e313e] -議事録 --２章なに言いたいかわからん --コミッター不足が引き起こす問題にプロセスの話いれたらいいかも --モジュールオーナーとコミッターを一緒に言うのは誤解を生みやすいのでやめたほうがいいかも --昇格プロセスの問題点は？ --2.4に候補者予測の必要性を定義 --コミッター候補者予測は２章へ --シンプルに書いてみたらいいのでは？ ---２章・目的 ---３章・先行研究 ---４章・アプローチ ---５章・実験 --データセットではなくデータセットの作成方法 ---データセット ---5.1対象プロジェクト ---5.2データセット作成方法 ---5.3基本統計量 --考察 ---最初に結果がどうかを言わないと ---使えるのか使えないのかを言った上で，false positiveとかの話を -DONE --修士論文執筆計画を立てる（目次構成も含めて） --輪講資料作成 --外れ値を除去した場合での予測 -TODO --予測がはずれた開発者の分析 --結果の章の執筆 ***2016年7月19日 [#hb2e313e] -議事録 --モジュールとは何かをしっかりと説明できるように --ロジスティック回帰分析の説明とかをしっかりとできるように --前のモデルと比較して今回の差分を強調 ---前回はRecallが高すぎて，全員をモジュールオーナーと判断していた ---今回は，予測すべきではない開発者を削減することで，精度がよくなった -DONE --予測をはずした開発者の分析 --フィルタリング方法を変えてやってみる --決定木の構築 -TODO --修士論文執筆計画を立てる（目次構成も含めて） --輪講資料作成 -- ***2016年7月11日 [#hb2e313e] -議事録 --オーナーは無視する --大事なのはコミット権限を持っていない開発者の中からモジュールを担当できそうな開発者をみつけること --いろいろパラメーターを変えてみてやってみる --モジュールの特徴を考える（複雑さ的な） -DONE --STEP1を完了する ---データの分布をみる ---ごみを除去して分布をみる ---ごみを除去したデータで予測してみる -TODO --予測をはずした開発者の分析 --フィルタリング方法を変えてやってみる ***2016年7月1日 [#hb2e313e] -議事録 --オーナーは無視する --大事なのはコミット権限を持っていない開発者の中からモジュールを担当できそうな開発者をみつけること --いろいろパラメーターを変えてみてやってみる --モジュールの特徴を考える（複雑さ的な） -DONE --技術的貢献メトリクス計測スクリプトの完成 --社会的貢献メトリクス計測スクリプトの作成 --ICIS発表練習および発表 -TODO --STEP1を完了する ---データの分布をみる ---ごみを除去して分布をみる ---ごみを除去したデータで予測してみる ***2016年6月24日 [#hb2e313e] -議事録 --オーナーは無視する --大事なのはコミット権限を持っていない開発者の中からモジュールを担当できそうな開発者をみつけること --いろいろパラメーターを変えてみてやってみる --モジュールの特徴を考える（複雑さ的な） -DONE --輪講資料作成 --TDMデータ作成（normal, 2gram, tf-idf） --コミッターとコミッターでない開発者が受けているコメント分析 --技術的貢献メトリクス計測スクリプトの作成(途中) -TODO --技術的貢献メトリクス計測スクリプトの完成 --社会的貢献メトリクス計測スクリプトの作成 --ICIS発表練習および発表 ***2016年6月14日 [#hb2e313e] -議事録 -DONE --小ゼミの発表資料作成 --コミッターとそうでない開発者が受けているコメント抽出 --2グラムのパターンをやってみた -TODO --輪講資料作成 --Android appのレビューデータでの評価実験 ***2016年6月10日 [#hb2e313e] -議事録 -DONE --SS参加 --Dont Touch my Code読む -TODO --小ゼミの発表資料作成 --コミッターとそうでない開発者が受けているコメント抽出 ***2016年6月1日 [#hb2e313e] -議事録 -DONE --SSのスライド作成 --リサーチクエスチョン考えた -TODO --SS参加 --Dont Touch my Code読む ***2016年5月25日 [#hb2e313e] -議事録 --評価するのは精度というよりどれくらい早くコミッターをみつけられたか --まずはリサーチクエスチョンをたてる --サニタイジングありなし，で比較 --don't cannot などの抽出 --コミッターからの評価とすべての開発者からの評価の比較 --いろんな場合の実験をしていってみせればいい --最低頻出回数はデータの分布をみて上位100単語を使えば50%は網羅できるとかにすべき --1000件のレビューデータをランダムに取得する場合は，複数回ランダムにとってきたときに結果が変わらないことを示す． -DONE --3パターンでレビューごとの頻出単語抽出 --輪講資料作成 -TODO --コミッターとそうでない開発者が受けているコメント抽出 --SSスライド作成 ***2016年5月18日 [#ld356afc] -議題 --カテゴリ問題をどう解くか？ ---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日 [#ld356afc] -議題 --コミッターからの評判をセンチメンタル分析して定量化してみては？ -DONE --モジュールオーナーを割り出してみる --モジュールオーナーの昇格前の活動を目視で分析する（途中） -TODO --モジュールオーナーの昇格前の活動を目視で分析する -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月28日 [#ld356afc] -議題 -DONE --すべてのプロジェクトでモジュール分割方法を再検討する --だれがモジュールオーナーにふさわしいのかを考える --Apacheのデータセットを増やす --モジュール分割方法からコンポーネント情報を逆引きして分割が正しそうか確かめる -TODO --モジュールオーナーを割り出してみる --モジュールオーナーの昇格前の活動を目視で分析する -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月21日 [#ld356afc] -議題 -DONE --WebKitプロジェクト以外のプロジェクトでの変更ファイルのリストアップをする（木曜日） --コミット数の多い開発者がどのファイルをよく変更しているかをリストアップする（金曜日） --輪講資料作成（月曜日） --実験のシナリオをまとめる（火曜日） --すべてのプロジェクトでモジュール分割方法を再検討する（水曜日） -TODO --だれがモジュールオーナーにふさわしいのかを考える（金曜日） ---Expertise Browserなどをみて --Apacheのデータセットを増やす（月曜日） --モジュール分割方法からコンポーネント情報を逆引きして分割が正しそうか確かめる（火曜日） --モジュールオーナーを割り出してみる（水曜日） -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月14日 [#ld356afc] -議題 --比較評価の方法は自分でモデルを複数作って行う -- -DONE --変更ファイルを取得 --メールは分析が終わってから --予定はたてたけど変わりそう -TODO --WebKitプロジェクト以外のプロジェクトでの変更ファイルのリストアップをする（木曜日） --コミット数の多い開発者がどのファイルをよく変更しているかをリストアップする（金曜日） --輪講資料作成（月曜日） --実験のシナリオをまとめる（火曜日） --すべてのプロジェクトでモジュール分割方法を再検討する（水曜日） -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年4月6日 [#ld356afc] -議題 --モジュールオーナーを必要としているかメールしてみてはどうか？ --スケジュールをまずたてましょう --Developer Initiation and Social Interactions in OSSとたたかうのもあり --モジュールオーナーに着目するという点は新規性があるからEMSE14と違いはある --まずはごみをしっかりとって予測ができるようにならなければ --モジュールオーナーの定義を再検討 --モジュールの分割方法を再検討 --人をみるということは多様性しかないので，一つのモデルでうまくいくとは思わない --モジュールごとに予測モデルが違うくてもおもしろい（UIはコメントが重要だけどCore部分はパッチが必要） -DONE --SIGSEでの発表 --コミッター予測の論文みつけて読んだ --データベース復元 --メールデータの取得 -TODO --計画をしっかりたてる --メールする文章を考える -STAY --モジュールオーナーの不足状況と昇格の関係を分析する --データで説明できない開発者の昇格前の活動をみる ***2016年3月1日 [#a6a37adf] -議題 --データで説明できない開発者の昇格前の活動をみる --現状ではパッチを一回でも投稿した開発者をいれて予測しているが，フィルターの仕方をデータの分布から判断する（5回できるべきでは？など） -DONE --不均衡データでの機械学習について調査 --アンダーサンプリングをして再実験 --SIGSE用スライド作成 --各モジュールのコミット数およびパッチ投稿数計測スクリプトの作成 -TODO --モジュールオーナーの不足状況と昇格の関係を分析する --SIGSEでの発表資料完成 --データで説明できない開発者の昇格前の活動をみる -SCHEDULE ***2016年2月23日 [#a6a37adf] -議題 --コミッターの分布をみる限りじゃ予測できなさそう --データをもっと詳しくみてからフィルタリング等を考えるべき --アンケートをとるのはデータをもっとみてから --予測はシミュレーションベースでやるべきでは？（Who is going to metntorみたいに） --まずはモジュールオーナーが少ない時期と昇格の関係をみよう -TODO --モジュールオーナーの不足状況と昇格の関係を分析する **作業日報 [#ke425ed4] ***2016年4月 [#mf7c2c26] -8日 --予定 ---メールを送る開発者をリストアップする ---メールの本文を考える ---EMSEの論文を読む --実績 ---メールを送る開発者をリストアップする ---メールの本文を考える -7日 --予定 ---メールを送る開発者をリストアップする ---メールの本文を考える ---EMSEの論文を読む -6日 --予定 ---ミーティング・予定たてる --実績 ---ミーティング・予定たてる ***2016年3月 [#mf7c2c26] -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月 [#mf7c2c26] -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日 --実績 ---再実験（パッチを投稿したことない人の完全削除） ---最新の文献調査 --予定 ---再実験（パッチを投稿したことない人の完全削除） ---最新の文献調査
テキスト整形のルールを表示する
添付ファイル:
進捗報告201608010.pdf
4件
[
詳細
]
yy_thesis_main.pdf
3件
[
詳細
]
FalseNegative-FalsePositive.pdf
3件
[
詳細
]
sigse191.pptx
3件
[
詳細
]
修正点と修正案.xlsx
[
詳細
]
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
進捗報告201608010.pdf 4件
[詳細]
yy_thesis_main.pdf 3件
[詳細]
FalseNegative-FalsePositive.pdf 3件
[詳細]
sigse191.pptx 3件
[詳細]
修正点と修正案.xlsx
[詳細]
