築山の履歴(No.52) - PukiWiki

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

Schedule†

	Mon	Tue	Wed	Thu	Fri
1
2	大ゼミ			全体	授業
3			授業
4
5	授業	授業

To Do†

6/28
- データ取りたい（python）
- まずはバージョン管理システムから
  - プロジェクトの調査
6/21
- 先行研究調査
  - 使われているメトリクスまとめる
5/17
- 走る
5/10
- 夏までは原因分析
- Grritさわる（〜??土曜か月曜くらい？）
  - gitリポジトリ作る

Done†

7/1
- 「Coderetreat for Girls」参加して来ましたCoderetreat_参加報告_0.pdf
6/28
- 大ゼミ発表（6/26）

6/21
- 大ゼミ発表資料作成大セ?ミ草稿2_60180081_20170626.key
- 概要作成大セ?ミ発表概要草稿1_20170621_1.txt
- 提出用スライド（載せるスライト?）60180081_20170626.pdf
  - GTの説明どうしましょ

6/5
- Aパターンに決定
  - 見逃しレビューの把握
- Bパターン
  - Security Bug に着目した見逃しレビューの特徴理解

5/31
- 論文読んだ中でマッピング（〜5/13）
- データどうしよう（〜5/17）
  - なんとかなる？

5/24
- SZZアルゴリズムに必要なデータを勉強？
  - When Do Changes Induce Fixes?.pdf
  - CVS（バージョン管理システム） × BUGZILLA（不具合管理システム）
- スライド作る
  - 発表草稿.pdf
  - 発表草稿.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図(大平画伯).pdf
3/22（2016）
- 20160322.pdf

4/19
- Buggyレビューの論文読む
- 他の論文も読む（何を目的に, 何のデータをとって, どんな考察をしているか）
  - "The Impact of Code Review Coverage and Code Review Participation on Software Quality"が引用されている論文（何となくやりたいことに近いかも？）

4/18
- 進捗管理_20170418.pdf

3/27
- サーベイ中（Buggy Review論文から, その参考文献などコードレビューと不具合に関する論文）
- 具体的に何するか決める

研究テーマ†

修論†

2017/6/16：大ゼミ発表スライド
プロジェクト調査
- https://docs.google.com/spreadsheets/d/1Udoau8VQMfib-8u3PNBo_OWW0FMHVxlhYhNrwMEJcqs/edit?usp=sharing

構想†

背景

目的
- レビュー時に人が見逃しやすいバグ（欠陥）の特徴を知りたい　＞　その先は？？？
  - できればケアレスミスでないやつ（理由は？？？まだ明確でない）
  - 人が気づかずに見逃してしまう欠陥
  - 経験がある人（どの程度？）でもレビューで見落としてしまう欠陥

アプローチ
- SZZでレビュー時に不具合になったものを取得
  - 理由：なんらかの　修正/変更　＞　レビュー　＞　コミットというプロセスを踏むので, レビュー後のコミットに不具合があった = レビュー見逃しとする（プロジェクトによるかも？）
- バグはHIBのうち, Security bugに注目する
  - 理由：有用性高そう（下心）, 短い時間で修正されるが, 再発の可能性が高い & 経験豊富な開発者が担当する場合が多い（らしい　＞　こっちのが主な理由）
  - Security bug担当　＞　ある程度経験があると判断？（要文献調査）

プロジェクト
- どうしましょう

もらった意見†

5/17
- missing bug（見逃しバグ）
- 個人に注目（この人がいるから, レビュー後の不具合が何%）
  - ベイズ理論

Memo（妄想）†

5/24
- コミットした人 or review+ にした人だけなら, 不具合管理票/historyから取得できる
- ただ, レビューの議論に参加した人は？？？不具合管理票にコメントはあるけどレビューの議論とは限らない
- レビューツール使ってるプロジェクトにすべき？？
  - あんまりなさそう

5/17
- 人（参加数など）に関する論文が多い. > レビュープロセスの性質上？
  - そもそもバグ = 見落とされたもの（レビュー後を見る必要性が少ない？ > コミットされたバグそのものを見ればいい）
  - ツールベースのレビューでは, コメントも見れるから？ > そっちの方が今までにないデータの使い道
- レビュー後のバグを見る意義
- 目の数を通過するバグは？
  - レビュー参加数が少ないバグ v.s レビュー参加数が多いバグ > 特徴に差があるか？
  - バグの特徴って？？？
- 目の数が増えることでどんなバグが防げるか

Memo†

レビューで見落とされるバグの特徴
- IPSJ-WWS2014012.pdf：OSS のレビューデータ分析におけるバグ見逃しコミットの取り扱いについて
- SES2015_sakaguchi_final.pdf：OSS開発におけるテストコードの保守頻度が与える欠陥混入への影響

「ロジスティック回帰分析と傾向スコア (propensity score) 解析」19_19-008.pdf
- 多変量解析において, 交絡因子（因子同士に相関がある場合）の影響を除去するために, 交絡要因になる共変量を縮約（一次元化）する方法
  - AIC（赤池の情報量基準）, VIF（分散拡大変数）
  - まとめてみたロシ?スティック回帰分析と傾向スコア（Propensity score）解析.pdf

Read Papers†

title	publication date	概要	所感	読んだ日	著者
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を引いてるやつ

タイトル	出版日	会議	著者	概要	所感	読んだ日
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 Dueñ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†

引き継ぎ（？）†

卒論タイトル：OSS開発における長期貢献者の特徴理解のための注目度と活動期間の関係分析

GitHubにおける注目度と長期貢献者の関係分析