![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
#author("2018-01-29T18:57:29+09:00","","") #author("2018-02-05T14:56:23+09:00","","") *Schedule [#q7b56221] |CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|c | |''Mon'' |''Tue'' |''Wed'' |''Thu''|''Fri''|h |1|| &color(red){全体MTG&br;(10:00-12:00)}; |||| |2||~|パターン認識||情報通信ネットワーク論| |3|ネットワーク情報論|都市環境デザイン論||マルチメディアコミュニケーション論|マルチメディアコミュニケーション論| |4|ソフトウェア工学特論||大ゼミ|人間・環境関係論|| |5||知識工学|||| ~ *研究テーマ [#xefd17e2] ***XXXXX[#a2b712a4] -論文書いてます --https://docs.google.com/document/d/198qam7pQbpfnZby-1ceAxf1F2WBb5FWMxvI2TSd_kx8/edit ***修論[#a2b712a4] -2017/6/16：大ゼミ発表スライド --&attachref(60180081_20170626.pdf); -プロジェクト調査 --https://docs.google.com/spreadsheets/d/1Udoau8VQMfib-8u3PNBo_OWW0FMHVxlhYhNrwMEJcqs/edit?usp=sharing -レビューデータ調査（ReviewBoard） --https://docs.google.com/spreadsheets/d/1t38A-boTeD-suhSV62_E6EjW4FW9-8bo0HxWY9g64zU/edit#gid=0 --レビューデータ構造（ReviewBoard） ---&attachref(レヒ?ューテ?ータ構造.pdf); -バグデータ調査 -- -リポジトリデータ調査 -- -11月まで予定 --- *2/5[#q5874f1c] **DONE [#o8fee665] **TODO [#q044dd96] - *1/29[#q5874f1c] **DONE [#o8fee665] **TODO [#q044dd96] - *1/9[#q5874f1c] **DONE [#o8fee665] -メールしたけどレビューの原因はわかっていない -レビューデータがあるバグは68件（4??件中） **TODO [#q044dd96] *12/25[#q5874f1c] **DONE [#o8fee665] -17件読んだ（32件/418件） --コメント多い30件から読みやすそうなのを選んだ -レビューコメントあんまり使っていない（or 使う人は決まってる感） **TODO [#q044dd96] -「レビュー見逃しの原因」 --見つけたらメールする *12/18[#q5874f1c] **DONE [#o8fee665] -3件読んだ（15件/418件） **TODO [#q044dd96] -20件 -コメントの多い順から -レビューコメント使っているか *12/11[#q5874f1c] **DONE [#o8fee665] -大ゼミ発表資料・概要の作成 -バグを数件読んだ **TODO [#q044dd96] -バグの目視件数増やす *12/4[#q5874f1c] **DONE [#o8fee665] -研究計画作成のためにreviewの論文を数本読んだ --Peer Review on Open-Source Software Projects: Parameters, Statistical Models, and Theory（2014，PETER C. RIGBY） ---インスペクションとピアレビュー（モダンコードレビュー？）を網羅的に比べた論文 --↑参考文献で，"インスペクション"のチェックリスト作成した論文があった -取得できたバグが418件（総不具合報告数：953件，期間2015/10/01〜2016/09/30） --だいたい半分 --先行研究は"コミット数"で判断している．．． **TODO [#q044dd96] -- -- *11/27[#q5874f1c] **DONE [#o8fee665] -- **TODO [#q044dd96] --とりあえずバグ読む（なんの議論） --コードレビューの論文読む *11/21[#q5874f1c] **DONE [#o8fee665] -- **TODO [#q044dd96] --大ゼミ資料（解決策提案） --バグ何件か読む *9/16 [#q5874f1c] **DONE [#o8fee665] --レビューデータDB格納完了 --method図書いた **TODO [#q044dd96] --Mozillaのプロセスの中身みる *9/27 [#q5874f1c] **DONE [#o8fee665] --レビューデータ取得 ---※まだまだ不備あり **TODO [#q044dd96] --論文書く（かけるところ・議論したいところ） ---第1章からは書かない *9/12 [#q5874f1c] **DONE [#o8fee665] --先日メールを送りました（今の所返事はなし） --論文読む（〜9/5） **TODO [#q044dd96] --実装（DB） *9/6 [#q5874f1c] **DONE [#o8fee665] -- **TODO [#q044dd96] --メール --論文読む（〜9/5） --実装（DB） *8/30 [#q5874f1c] **DONE [#o8fee665] --遅れてます --何をしたらいいのやら **TODO [#q044dd96] --メール？ --アプローチ書く *8/2 [#q5874f1c] **DONE [#o8fee665] --レビューのデータ構造の理解 --レビューデータ取得プログラムできた？ ---何件かレビューデータを取得してみた（JSON） ---データがidのうち奇数しかない（データが74,610） **TODO [#q044dd96] --ソースコード取得プログラム --研究発表会 *7/26 [#q5874f1c] **DONE [#o8fee665] --計画を立ててみた **TODO [#q044dd96] --レビューのデータ構造の理解 --プログラム作成？ *フォーマット [#q5874f1c] **DONE [#o8fee665] -- **TODO [#q044dd96] -- *To Do [#x605305d] -6/28 --データ取りたい --まずはバージョン管理システムから ---プロジェクトの調査 -6/21 --先行研究調査 ---使われているメトリクスまとめる -5/17 --走る -5/10 --夏までは原因分析 --Grritさわる（〜??土曜か月曜くらい？） ---gitリポジトリ作る *Done [#x605305d] -7/25 --計画を立てる --データ（レビューシステム, 不具合管理システム, バージョン管理システム）の理解 ---ReviewBoad（上述） --アカウント作ってプロジェクトの調査（現在はopen>closedを見た） -7/1 --「Coderetreat for Girls」 参加して来ました ---&attachref(Coderetreat_参加報告_1.pdf); -6/28 --大ゼミ発表（6/26） -6/21 --大ゼミ発表資料作成&attachref(大セ?ミ草稿2_60180081_20170626.key); --概要作成&attachref(大セ?ミ発表概要草稿1_20170621_1.txt); --提出用スライド&attachref(（載せるスライト?）60180081_20170626.pdf); ---GTの説明どうしましょ -6/5 --Aパターンに決定 ---見逃しレビューの把握 --Bパターン ---Security Bug に着目した見逃しレビューの特徴理解 -5/31 ---論文読んだ中でマッピング（〜5/13） --データどうしよう（〜5/17） ---なんとかなる？ -5/24 --SZZアルゴリズムに必要なデータを勉強？ ---&attachref(When Do Changes Induce Fixes?.pdf); ---CVS（バージョン管理システム） × BUGZILLA（不具合管理システム） --スライド作る ---&attachref(発表草稿.pdf); ---&attachref(発表草稿.key); -5/17 --MTG ---テストを通るバグと, レビューを通るバグは違う ---目的は？（バグを減らす可能性を高める or レビュープロセスの改善（このタイプの人がいたら, この不具合は治まるというのを提案？）） --論文内容をさらっと理解（〜5/12） -5/12 --論文翻訳機にかける[1, %%2, 3, 4, 5, 6, 7, 8, 9, 10, 11%%]（〜5/11） > [1]ない -5/10 --MTG&attachref(図(大平画伯).pdf); -3/22（2016） --&attachref(20160322.pdf); -4/19 --Buggyレビューの論文読む --他の論文も読む（何を目的に, 何のデータをとって, どんな考察をしているか） ---"The Impact of Code Review Coverage and Code Review Participation on Software Quality"が引用されている論文（何となくやりたいことに近いかも？） -4/18 --&attachref(進捗管理_20170418.pdf); -3/27 --サーベイ中（Buggy Review論文から, その参考文献などコードレビューと不具合に関する論文） --具体的に何するか決める *研究テーマ [#xefd17e2] ***構想[#a2b712a4] -背景 -目的 --レビュー時に人が見逃しやすいバグ（欠陥）の特徴を知りたい ＞ その先は？？？ ---できればケアレスミスでないやつ（理由は？？？まだ明確でない） ---人が気づかずに見逃してしまう欠陥 ---経験がある人（どの程度？）でもレビューで見落としてしまう欠陥 -アプローチ --SZZで''レビュー時''に不具合になったものを取得 ---理由：なんらかの 修正/変更 ＞ レビュー ＞ コミットというプロセスを踏むので, レビュー後のコミットに不具合があった = レビュー見逃しとする（プロジェクトによるかも？） --バグはHIBのうち, Security bugに注目する ---理由：有用性高そう（下心）, 短い時間で修正されるが, 再発の可能性が高い & 経験豊富な開発者が担当する場合が多い（らしい ＞ こっちのが主な理由） ---Security bug担当 ＞ ある程度経験があると判断？（要文献調査） --プロジェクト ---どうしましょう **もらった意見 [#zea31ae8] -5/17 --missing bug（見逃しバグ） --個人に注目（この人がいるから, レビュー後の不具合が何%） ---ベイズ理論 *Memo（妄想） [#zea31ae8] -5/24 --コミットした人 or review+ にした人だけなら, 不具合管理票/historyから取得できる --ただ, レビューの議論に参加した人は？？？不具合管理票にコメントはあるけどレビューの議論とは限らない --レビューツール使ってるプロジェクトにすべき？？ ---あんまりなさそう -5/17 --''人''（参加数など）に関する論文が多い. > レビュープロセスの性質上？ ---そもそもバグ = 見落とされたもの（レビュー後を見る必要性が少ない？ > コミットされたバグそのものを見ればいい） ---ツールベースのレビューでは, コメントも見れるから？ > そっちの方が今までにないデータの使い道 --レビュー後のバグを見る意義 --''目の数''を通過するバグは？ ---レビュー参加数が少ないバグ v.s レビュー参加数が多いバグ > 特徴に差があるか？ ---バグの特徴って？？？ --''目の数''が増えることでどんなバグが防げるか *Memo [#zea31ae8] -レビューで見落とされるバグの特徴 --&attachref(IPSJ-WWS2014012.pdf);：OSS のレビューデータ分析におけるバグ見逃しコミットの取り扱いについて --&attachref(SES2015_sakaguchi_final.pdf);：OSS開発におけるテストコードの保守頻度 が与える欠陥混入への影響 -「ロジスティック回帰分析と&color(red){傾向スコア (propensity score)}; 解析」&attachref(19_19-008.pdf); --多変量解析において, 交絡因子（因子同士に相関がある場合）の影響を除去するために, 交絡要因になる共変量を縮約（一次元化）する方法 ---AIC（赤池の情報量基準）, VIF（分散拡大変数） ---まとめてみた&attachref(ロシ?スティック回帰分析と傾向スコア（Propensity score）解析.pdf); * Read Papers [#v6491946] |CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|c | title | publication date | 概要 | 所感 | 読んだ日 | 著者 |h | Investigating code review quality: Do people and participation matter? | 2015/11/23 ||||| | The Impact of Code Review Coverage and Code Review Participation on Software Quality | | コードレビューカバレッジ / 参加とのソフトウェアの品質（欠陥数）の関係を定量的に調査した. レビューの範囲が小さい / レビュー参加者が少ない 場合, ソフトウェアの品質に関係する. | レビューからソフトウェアの品質を見ているのが面白い ||| -The Impact of Code Review Coverage and Code Review Participation on Software Qualityを引いてるやつ |CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|CENTER:|c | タイトル | 出版日 | 会議 | 著者| 概要 | 所感 | 読んだ日 |h | Lessons Learned from Building and Deploying a Code Review Analytics Platform | 15/05/16 | MSR'15 | Christian Bird, Trevor Carnahan, Michaela Greiler | CodeFlow（Microsoftが開発した社内コードレビューツール）Anarycs の設計, 導入, サポートに関する調査 | インタビュー（商用製品にもコードレビューツール使われていますアピールはできそう） | | | Characterization of the Xen Project Code Review Process: an Experience Report | 16/05/14 | MSR'16 | Daniel Izquierdo-Cortazar, Lars Kurth, Jesus M. Gonzalez-Barahona, Santiago Dueñas, Nelson Sekitoleko | コードレビュー＞マージまでの時間.（コードレビュープロセスの分析） 2012年に比べて2014年は時間が長くなる. 5つ以上の複数のパッチがあるレビューは時間が長くなる. | レビュープロセスに着目. 時間の増加=コミュニケーションの増加>プロセスの悪化？何が見たいか謎. レビュデータの取得方法については参考になる（VCSから正規表現でパッチを取得.レビューデータはML ＜×） | | | Characteristics of Useful Code Reviews: An Empirical Study at Microsoft | 15/05/16 | MSR'15 | Amiangshu Bosu, Michaela Greiler, Christian Bird | コードレビューの有用性（useful）の調査. インタビューして単語から分類 > 自動的に分類できるような足がかり | '有用なコードレビューを特定' > 大きく見たらやりたいことは似てるかも. ただ, インタビューは無理？（Microsoft） | | | Expectations, Outcomes, and Challenges of Modern Code Review | | ICSE'13 | | (CodeFolowにて)MCRをする動機, 結果が期待に合っているか, MCRの課題についてインタビュー調査 | コードレビューを行う開発者の意識を調査したものは面白いけど, 対象がCodeFlow, インタービュー（研究の動機あたりの参考文献にはできる）| | | | | | | | | | | The Emotional Side of Software Developers in JIRA | | MSR'16 | | ソフトウェアへのコメントの感情がソフトウェアの品質に影響するか | バグ修正時間とコメントの感情との関係に相関があるらしい？ | | //| | | | | | | | *BookMark [#zea31ae8] *引き継ぎ（？） [#zea31ae8] 卒論タイトル：OSS開発における長期貢献者の特徴理解のための注目度と活動期間の関係分析 -[[GitHubにおける注目度と長期貢献者の関係分析]]
