1. OSS開発におけるレビュアー間の
開発におけるレビュアー間の
合意形成の分析
奈良先端科学技術大学院大学
○林宏徳 伊原彰紀 松本健一
林宏徳, 伊原彰紀,
林宏徳

2. 背景
• OSSユーザはバグを発見した時、OSSコミュニティに報告する
バグ直して!!
OSSコミュニティ
2

3. 背景
• OSSユーザはバグを発見した時、OSSコミュニティに報告する
• 大規模OSSコミュニティには日々大量のバグ報告が届く
例） Mozilla Project: 平均300件/日
• 開発者は大量のバグに対して，効率の良い修正を行う必要がある
・・・。
OSSコミュニティ
3

4. バグ修正プロセス
バグ修正プロセス
修正
報告者
管理人
修正者
レビュアー
プロダクト
報告
割り当て
修正
検証
更新
平均149日
4

5. バグ修正プロセス
バグ修正プロセス
コードの誤りを発見
発見
できない場合がある
できない
報告者
管理人
修正者
レビュアー
プロダクト
報告
割り当て
修正
検証
更新
平均149日
5

6. バグ修正プロセス
バグ修正プロセス
報告者
管理人
修正者
レビュアー
プロダクト
報告
割り当て
修正
検証
更新
再修正
不具合の修正が不十分 不適切
不十分/不適切
不十分 不適切な場合
修正コストの増大
(平均，149日 → 371 日)
6

7. 検証（レビュー）
• 大規模な開発ではひとつのバグ修正に複数人のレビュ
アーが関わる[Peter, 2013]
• OSS開発における協調作業には困難な側面もある[Abreu, 2009]
修正が承認される
承認される場合
１. 修正が承認される場合
OK!!
OK!!
修正しました
OK!!
修正者
レビュアー
プロダクト
7

8. 検証（レビュー）
• 大規模な開発ではひとつのバグ修正に複数人のレビュ
アーが関わる[Peter, 2013]
• OSS開発における協調作業には困難な側面もある[Abreu, 2009]
修正が否決される
否決される場合
２. 修正が否決される場合
No!!
No!!
修正しました
No!!
修正者
レビュアー
プロダクト
8

9. 検証（レビュー）
• 大規模な開発ではひとつのバグ修正に複数人のレビュ
アーが関わる[Peter, 2013]
• OSS開発における協調作業には困難な側面もある[Abreu, 2009]
3. 意見が分かれる場合
意見が分かれる場合
OK!!
No!!
修正しました
OK!!
修正者
レビュアー
プロダクト
9

10. 検証（レビュー）
• 本来は正しい意見を無視してプロダクトを更新した場合，
再修正が起こると予想される
OK
No!!
OK
修正者
レビュアー
プロダクト
仮説: 合意形成が得られなかったレビューには
再修正が多く発生する
10

11. 本研究のねらいとRQ
本研究のねらいと
Goal
•
再修正の発生を防ぐために，合意形成に着目し，レビュアーの活動
を理解する
Research Questions
1.
何人のレビュアーがひとつのバグ修正に関わっているか？
何人のレビュアー
2.
レビュアー間の合意形成は行われているか？
合意形成は行われているか？
3.
レビュアー間の合意形成とバグの再修正は関係しているか？
合意形成とバグの再修正は関係しているか？
合意形成とバグ
11

12. 分析
12

13. 分析対象
プロジェクト：Openstack project
レビューツール: Gerrit Code Review
期間
：2010-2012
データ：2,539 件のレビュー記録
レビュアーは各自，投稿されたコードに
評価を付けることができる
• コアレビュアー: [+2, +1, 0, -1, -2]
• 一般レビュアー: [
+1, 0, -1
]
Gerrit Code Reviewの一画
面
13

14. RQ1: 何人のレビュアーがひとつのバグ修正
に関わっているか？
動機
• どのように合意形成が行われているのかを明らかにする
分析方法
どれくらい議論している？
• 各レビューに関する以下の
基本統計量を計測する
• ファイル数
• レビュアー数
• レビュアーの発言数
・・・
・・
・
・・・
何人？
何ファイルが
対象？
14

15. RQ1: 何人のレビュアーがひとつのバグ修正
何人のレビュアーがひとつのバグ
バグ修正
に関わっているか？
• 1-3ファイルが一度にレビューされる
ファイル
• およそ4人のレビュアーがひとつの不具合修正に関わる
およそ4
最小値
中央値
平均値
最大値
ファイル数
0
1
2.93
164
レビュアー数
1
4
4.41
18
コメント数
0
4
6.37
62
15

16. RQ2: レビュアー間の合意形成は行われている
か?
動機
• レビューにおける合意形成の有無について理解する
分析方法
1.
2.
承認済みのレビューを対象に，各レビュアーの評価を収集する
成功/失敗に各レビューを分類する
合意形成 成功/失敗
OK!!
OK!!
OK!!
成功：
合意形成 成功 全ての評価に
負の評価(“-1”or “-2”)を含まない
OK!!
No!!
OK!!
失敗：
合意形成 失敗 評価にひとつでも
負の評価(“-1”or “-2”)を含む
16

17. RQ2: レビュアー間の合意形成は行われている
か?
レビュー件数
• 90％以上のレビューは合意に基づいているが，合意形成が行われない
ままプロダクトに修正が反映されることもある
合意形成 成功
合意形成 失敗
17

18. RQ3: レビュアー間の合意形成と不具合の
再修正は関係しているか?
再修正は関係しているか
動機
• 合意形成の観点から，再修正の発生を防止する手がかり
手がかりを調査する
手がかり
分析方法
• RQ2の分析で分類されたレビューを“再修正の有無”について再度分
類する
OK!!
OK!!
再修正あり
再修正あり
No!!
OK!!
再修正なし
合意形成 成功
再修正なし
合意形成 失敗
18

19. RQ3: レビュアー間の合意形成と不具合の
再修正は関係しているか?
再修正は関係しているか
• 関係あり．再修正の発生率に有意な差(p>0.01)がみられた
合意形成 成功
OK!!
合意形成 失敗
OK!!
OK!!
L
OK!!
No!!
OK!!
15.81%が再修正
25.00%が再修正
19

20. 議論内容の紹介
20

21. 合意形成に成功した議論の例
合意形成に成功した議論の例
形成に成功
パッチを投稿しました
これで良いと思います
Alex (修正者)
Johannes(レビュアー)
ダメです．デシリアライズにまだ
問題があるように思えます(以下略
Vish (レビュアー)
パッチを再度投稿しました
これならOKです！
これなら です！
Alex
実際の議論 (ID: 5749)
Vish
21

22. 合意形成に成功した議論の例
合意形成に成功した議論の例
形成に成功
パッチを投稿しました
これで良いと思います
Alex (修正者)
Johannes(レビュアー)
再修正なし
ֵ◌
ダメです．デシリアライズにまだ
問題があるように思えます(以下略
Vish (レビュアー)
再修正あり
パッチを再度投稿しました
これならOKです！
これなら です！
Alex
実際の議論 (ID: 5749)
Vish
22

23. 合意形成が失敗した議論の例
合意形成が失敗した議論の例
形成が失敗
パッチを投稿しました
この書き方は良くない
Peng (修正者) です．直しましょう
直しましょう．
直しましょう
Willian(レビュアー)
過去にこのやり方でやっているし，
大丈夫じゃないですか？
Peng
私にはなぜそうするのか理解で
きません．こうなったら他の人
の意見を聞いてみましょう
Willian
このコードで です
このコードでOKです
コードで
Salvatore (レビュアー)
実際の議論 (ID: 5220)
23

24. 合意形成が失敗した議論の例
合意形成が失敗した議論の例
形成が失敗
パッチを投稿しました
この書き方は良くない
Peng (修正者) です．直しましょう
直しましょう．
直しましょう
Willian(レビュアー)
再修正なし
過去にこのやり方でやっているし，
大丈夫じゃないですか？
Peng
再修正あり
私にはなぜそうするのか理解で
きません．こうなったら他の人
の意見を聞いてみましょう
Willian
このコードで です
このコードでOKです
コードで
Salvatore (レビュアー)
実際の議論 (ID: 5220)
24

25. まとめ
25

26. まとめ
目的：修正コスト増大を防ぐため，再修正を防ぐヒントを得る
目的
分析：レビュアーの合意形成を分析した
分析
結果：レビュアーの合意形成の失敗は再修正の予兆
合意形成の失敗は再修正の予兆である
結果
合意形成の失敗は再修正の予兆
衠 ֳ◌
OK!
No!!
OK!
報告者
管理人
修正者
報告
割り当て
修正
レビュアー
レビュー
プロダクト
更新
再修正
26

27. 展望
• 分析
• レビュアー間の議論を分類
• 対象プロジェクトの追加
• 合意形成の支援
• ツールの作成
• 議論ルールの作成
27

28. DISCUSS Your Review
until Reaching Consensus!!
냰
Thank you.