\n \n \n
\n
\n\n \n \n \n \n \n 🏆[Award]🏆The review linkage graph for code review analytics: A recovery approach and empirical study.\n \n \n \n\n\n \n Toshiki Hirao; Shane McIntosh; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In
ESEC/FSE 2019 - Proceedings of the 2019 27th ACM Joint Meeting European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2019. \n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@inproceedings{\n title = {🏆[Award]🏆The review linkage graph for code review analytics: A recovery approach and empirical study},\n type = {inproceedings},\n year = {2019},\n keywords = {Code review,Mining software repositories,Software analytics},\n id = {072eb792-ecab-3c94-a7aa-c6568b200797},\n created = {2022-08-02T01:00:46.155Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-26T05:55:43.021Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Modern Code Review (MCR) is a pillar of contemporary quality assurance approaches, where developers discuss and improve code changes prior to integration. Since review interactions (e.g., comments, revisions) are archived, analytics approaches like reviewer recommendation and review outcome prediction have been proposed to support the MCR process. These approaches assume that reviews evolve and are adjudicated independently; yet in practice, reviews can be interdependent. In this paper, we set out to better understand the impact of review linkage on code review analytics. To do so, we extract review linkage graphs where nodes represent reviews, while edges represent recovered links between reviews. Through a quantitative analysis of six software communities, we observe that (a) linked reviews occur regularly, with linked review rates of 25% in OpenStack, 17% in Chromium, and 3%-8% in Android, Qt, Eclipse, and Libreoffice; and (b) linkage has become more prevalent over time. Through qualitative analysis, we discover that links span 16 types that belong to five categories. To automate link category recovery, we train classifiers to label links according to the surrounding document content. Those classifiers achieve F1-scores of 0.71-0.79, at least doubling the F1-scores of a ZeroR baseline. Finally, we show that the F1-scores of reviewer recommenders can be improved by 37%-88% (5-14 percentage points) by incorporating information from linked reviews that is available at prediction time. Indeed, review linkage should be exploited by future code review analytics.},\n bibtype = {inproceedings},\n author = {Toshiki Hirao, undefined and Shane McIntosh, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/3338906.3338949},\n booktitle = {ESEC/FSE 2019 - Proceedings of the 2019 27th ACM Joint Meeting European Software Engineering Conference and Symposium on the Foundations of Software Engineering}\n}
\n
\n\n\n
\n Modern Code Review (MCR) is a pillar of contemporary quality assurance approaches, where developers discuss and improve code changes prior to integration. Since review interactions (e.g., comments, revisions) are archived, analytics approaches like reviewer recommendation and review outcome prediction have been proposed to support the MCR process. These approaches assume that reviews evolve and are adjudicated independently; yet in practice, reviews can be interdependent. In this paper, we set out to better understand the impact of review linkage on code review analytics. To do so, we extract review linkage graphs where nodes represent reviews, while edges represent recovered links between reviews. Through a quantitative analysis of six software communities, we observe that (a) linked reviews occur regularly, with linked review rates of 25% in OpenStack, 17% in Chromium, and 3%-8% in Android, Qt, Eclipse, and Libreoffice; and (b) linkage has become more prevalent over time. Through qualitative analysis, we discover that links span 16 types that belong to five categories. To automate link category recovery, we train classifiers to label links according to the surrounding document content. Those classifiers achieve F1-scores of 0.71-0.79, at least doubling the F1-scores of a ZeroR baseline. Finally, we show that the F1-scores of reviewer recommenders can be improved by 37%-88% (5-14 percentage points) by incorporating information from linked reviews that is available at prediction time. Indeed, review linkage should be exploited by future code review analytics.\n
\n\n\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n Message from the Chairs.\n \n \n \n\n\n \n Keisuke Hotta; Takao Nakagawa; Kazuhiro Yamashita; Marco Aurelio Gerosa; and Akinori Ihara\n\n\n \n\n\n\n In
Proceedings - 2019 10th International Workshop on Empirical Software Engineering in Practice, IWESEP 2019, 2019. \n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@inproceedings{\n title = {Message from the Chairs},\n type = {inproceedings},\n year = {2019},\n id = {43ebc16b-1e18-38b5-9a80-1abee4a0486e},\n created = {2022-08-02T01:00:48.895Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-23T02:08:22.649Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n bibtype = {inproceedings},\n author = {Keisuke Hotta, undefined and Takao Nakagawa, undefined and Kazuhiro Yamashita, undefined and Marco Aurelio Gerosa, undefined and Akinori Ihara, undefined},\n doi = {10.1109/IWESEP49350.2019.00005},\n booktitle = {Proceedings - 2019 10th International Workshop on Empirical Software Engineering in Practice, IWESEP 2019}\n}
\n
\n\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n An empirical study of README contents for java script packages.\n \n \n \n\n\n \n Shohei Ikeda; Akinori Ihara; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n
IEICE Transactions on Information and Systems, (2). 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@article{\n title = {An empirical study of README contents for java script packages},\n type = {article},\n year = {2019},\n keywords = {Association rule mining,Documentation,JavaScript packages,README},\n id = {9a24a578-69dc-31bc-ae01-a31b5e31837e},\n created = {2022-08-02T01:00:56.873Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-19T05:08:10.419Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Contemporary software projects often utilize a README. md to share crucial information such as installation and usage examples related to their software. Furthermore, these files serve as an important source of updated and useful documentation for developers and prospective users of the software. Nonetheless, both novice and seasoned developers are sometimes unsure of what is required for a good README file. To understand the contents of README, we investigate the contents of 43,900 JavaScript packages. Results show that these packages contain common content themes (i.e., ‘usage’, ‘install’ and ‘license’). Furthermore, we find that application-specific packages more frequently included content themes such as ‘options’, while library-based packages more frequently included other specific content themes (i.e., ‘install’ and ‘license’).},\n bibtype = {article},\n author = {Shohei Ikeda, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1587/transinf.2018EDP7071},\n journal = {IEICE Transactions on Information and Systems},\n number = {2}\n}
\n
\n\n\n
\n Contemporary software projects often utilize a README. md to share crucial information such as installation and usage examples related to their software. Furthermore, these files serve as an important source of updated and useful documentation for developers and prospective users of the software. Nonetheless, both novice and seasoned developers are sometimes unsure of what is required for a good README file. To understand the contents of README, we investigate the contents of 43,900 JavaScript packages. Results show that these packages contain common content themes (i.e., ‘usage’, ‘install’ and ‘license’). Furthermore, we find that application-specific packages more frequently included content themes such as ‘options’, while library-based packages more frequently included other specific content themes (i.e., ‘install’ and ‘license’).\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n Identifying and predicting key features to support bug reporting.\n \n \n \n\n\n \n Md. Rejaul Karim; Akinori Ihara; Eunjong Choi; and Hajimu Iida\n\n\n \n\n\n\n
Journal of Software: Evolution and Process, 31(12). 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@article{\n title = {Identifying and predicting key features to support bug reporting},\n type = {article},\n year = {2019},\n keywords = {bug report,open-source projects,prediction models},\n volume = {31},\n id = {2ba8ff8d-542e-3c76-bc95-a36d2b10f8b7},\n created = {2022-08-02T01:01:02.493Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-19T05:37:11.678Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Bug reports are the primary means through which developers triage and fix bugs. To achieve this effectively, bug reports need to clearly describe those features that are important for the developers. However, previous studies have found that reporters do not always provide such features. Therefore, we first perform an exploratory study to identify the key features that reporters frequently miss in their initial bug report submissions. Then, we propose an approach that predicts whether reporters should provide certain key features to ensure a good bug report. A case study of the bug reports for Camel, Derby, Wicket, Firefox, and Thunderbird projects shows that Steps to Reproduce, Test Case, Code Example, Stack Trace, and Expected Behavior are the additional features that reporters most often omit from their initial bug report submissions. We also find that these features significantly affect the bug-fixing process. On the basis of our findings, we build and evaluate classification models using four different text-classification techniques to predict key features by leveraging historical bug-fixing knowledge. The evaluation results show that our models can effectively predict the key features. Our comparative study of different text-classification techniques shows that naïve Bayes multinomial (NBM) outperforms other techniques. Our findings can benefit reporters to improve the contents of bug reports.},\n bibtype = {article},\n author = {Md. Rejaul Karim, undefined and Akinori Ihara, undefined and Eunjong Choi, undefined and Hajimu Iida, undefined},\n doi = {10.1002/smr.2184},\n journal = {Journal of Software: Evolution and Process},\n number = {12}\n}
\n
\n\n\n
\n Bug reports are the primary means through which developers triage and fix bugs. To achieve this effectively, bug reports need to clearly describe those features that are important for the developers. However, previous studies have found that reporters do not always provide such features. Therefore, we first perform an exploratory study to identify the key features that reporters frequently miss in their initial bug report submissions. Then, we propose an approach that predicts whether reporters should provide certain key features to ensure a good bug report. A case study of the bug reports for Camel, Derby, Wicket, Firefox, and Thunderbird projects shows that Steps to Reproduce, Test Case, Code Example, Stack Trace, and Expected Behavior are the additional features that reporters most often omit from their initial bug report submissions. We also find that these features significantly affect the bug-fixing process. On the basis of our findings, we build and evaluate classification models using four different text-classification techniques to predict key features by leveraging historical bug-fixing knowledge. The evaluation results show that our models can effectively predict the key features. Our comparative study of different text-classification techniques shows that naïve Bayes multinomial (NBM) outperforms other techniques. Our findings can benefit reporters to improve the contents of bug reports.\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n What Are the Perception Gaps Between FLOSS Developers and SE Researchers?: A Case of Bug Finding Research.\n \n \n \n\n\n \n Yutaro Kashiwa; Akinori Ihara; and Masao Ohira\n\n\n \n\n\n\n Volume 556 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@book{\n title = {What Are the Perception Gaps Between FLOSS Developers and SE Researchers?: A Case of Bug Finding Research},\n type = {book},\n year = {2019},\n source = {IFIP Advances in Information and Communication Technology},\n keywords = {High impact bug,Interview,Open source software},\n volume = {556},\n id = {49d4e2ae-488d-3b5e-9d47-008b2d28df54},\n created = {2022-08-02T01:01:04.245Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-23T01:35:45.629Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {In recent years, many researchers in the SE community have been devoting considerable efforts to provide FLOSS developers with a means to quickly find and fix various kinds of bugs in FLOSS products such as security and performance bugs. However, it is not exactly sure how FLOSS developers think about bugs to be removed preferentially. Without a full understanding of FLOSS developers’ perceptions of bug finding and fixing, researchers’ efforts might remain far away from FLOSS developers’ needs. In this study, we interview 322 notable GitHub developers about high impact bugs to understand FLOSS developers’ needs for bug finding and fixing, and we manually inspect and classify developers’ answers (bugs) by symptoms and root causes of bugs. As a result, we show that security and breakage bugs are highly crucial for FLOSS developers. We also identify what kinds of high impact bugs should be studied newly by the SE community to help FLOSS developers.},\n bibtype = {book},\n author = {Yutaro Kashiwa, undefined and Akinori Ihara, undefined and Masao Ohira, undefined},\n doi = {10.1007/978-3-030-20883-7_5}\n}
\n
\n\n\n
\n In recent years, many researchers in the SE community have been devoting considerable efforts to provide FLOSS developers with a means to quickly find and fix various kinds of bugs in FLOSS products such as security and performance bugs. However, it is not exactly sure how FLOSS developers think about bugs to be removed preferentially. Without a full understanding of FLOSS developers’ perceptions of bug finding and fixing, researchers’ efforts might remain far away from FLOSS developers’ needs. In this study, we interview 322 notable GitHub developers about high impact bugs to understand FLOSS developers’ needs for bug finding and fixing, and we manually inspect and classify developers’ answers (bugs) by symptoms and root causes of bugs. As a result, we show that security and breakage bugs are highly crucial for FLOSS developers. We also identify what kinds of high impact bugs should be studied newly by the SE community to help FLOSS developers.\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n The impact of human factors on the participation decision of reviewers in modern code review.\n \n \n \n\n\n \n Shade Ruangwan; Patanamon Thongtanunam; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n
Empirical Software Engineering, 24(2). 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@article{\n title = {The impact of human factors on the participation decision of reviewers in modern code review},\n type = {article},\n year = {2019},\n keywords = {Developer collaboration,Modern code review,Reviewer participation},\n volume = {24},\n id = {6b6e6536-dd4f-3754-af44-7f34bc82b096},\n created = {2022-08-02T01:01:15.709Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-23T01:12:45.399Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Modern Code Review (MCR) plays a key role in software quality practices. In MCR process, a new patch (i.e., a set of code changes) is encouraged to be examined by reviewers in order to identify weaknesses in source code prior to an integration into main software repositories. To mitigate the risk of having future defects, prior work suggests that MCR should be performed with sufficient review participation. Indeed, recent work shows that a low number of participated reviewers is associated with poor software quality. However, there is a likely case that a new patch still suffers from poor review participation even though reviewers were invited. Hence, in this paper, we set out to investigate the factors that are associated with the participation decision of an invited reviewer. Through a case study of 230,090 patches spread across the Android, LibreOffice, OpenStack and Qt systems, we find that (1) 16%-66% of patches have at least one invited reviewer who did not respond to the review invitation; (2) human factors play an important role in predicting whether or not an invited reviewer will participate in a review; (3) a review participation rate of an invited reviewers and code authoring experience of an invited reviewer are highly associated with the participation decision of an invited reviewer. These results can help practitioners better understand about how human factors associate with the participation decision of reviewers and serve as guidelines for inviting reviewers, leading to a better inviting decision and a better reviewer participation.},\n bibtype = {article},\n author = {Shade Ruangwan, undefined and Patanamon Thongtanunam, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/s10664-018-9646-1},\n journal = {Empirical Software Engineering},\n number = {2}\n}
\n
\n\n\n
\n Modern Code Review (MCR) plays a key role in software quality practices. In MCR process, a new patch (i.e., a set of code changes) is encouraged to be examined by reviewers in order to identify weaknesses in source code prior to an integration into main software repositories. To mitigate the risk of having future defects, prior work suggests that MCR should be performed with sufficient review participation. Indeed, recent work shows that a low number of participated reviewers is associated with poor software quality. However, there is a likely case that a new patch still suffers from poor review participation even though reviewers were invited. Hence, in this paper, we set out to investigate the factors that are associated with the participation decision of an invited reviewer. Through a case study of 230,090 patches spread across the Android, LibreOffice, OpenStack and Qt systems, we find that (1) 16%-66% of patches have at least one invited reviewer who did not respond to the review invitation; (2) human factors play an important role in predicting whether or not an invited reviewer will participate in a review; (3) a review participation rate of an invited reviewers and code authoring experience of an invited reviewer are highly associated with the participation decision of an invited reviewer. These results can help practitioners better understand about how human factors associate with the participation decision of reviewers and serve as guidelines for inviting reviewers, leading to a better inviting decision and a better reviewer participation.\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n 🏆[Award]🏆Mining Source Code Improvement Patterns from Similar Code Review Works.\n \n \n \n\n\n \n Yuki Ueda; Takashi Ishio; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In
IWSC 2019 - 2019 IEEE 13th International Workshop on Software Clones, 2019. \n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@inproceedings{\n title = {🏆[Award]🏆Mining Source Code Improvement Patterns from Similar Code Review Works},\n type = {inproceedings},\n year = {2019},\n keywords = {code review,sequential pattern mining,source code changes},\n id = {73e5541b-f411-302c-8858-e01e049f0df3},\n created = {2022-08-02T01:01:27.541Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-26T05:53:39.790Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Code review is key to ensuring the absence of potential issues in source code. Code reviewers spend a large amount of time to manually check submitted patches based on their knowledge. Since a number of patches sometimes have similar potential issues, code reviewers need to suggest similar source code changes to patch authors. If patch authors notice similar code improvement patterns by themselves before submitting to code review, reviewers' cost would be reduced. In order to detect similar code changes patterns, this study employs a sequential pattern mining to detect source code improvement patterns that frequently appear in code review history. In a case study using a code review dataset of the OpenStack project, we found that the detected patterns by our proposed approach included effective examples to improve patches without reviewers' manual check. We also found that the patterns have been changed in time series; our pattern mining approach timely achieves to track the effective code improvement patterns.},\n bibtype = {inproceedings},\n author = {Yuki Ueda, undefined and Takashi Ishio, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/IWSC.2019.8665852},\n booktitle = {IWSC 2019 - 2019 IEEE 13th International Workshop on Software Clones}\n}
\n
\n\n\n
\n Code review is key to ensuring the absence of potential issues in source code. Code reviewers spend a large amount of time to manually check submitted patches based on their knowledge. Since a number of patches sometimes have similar potential issues, code reviewers need to suggest similar source code changes to patch authors. If patch authors notice similar code improvement patterns by themselves before submitting to code review, reviewers' cost would be reduced. In order to detect similar code changes patterns, this study employs a sequential pattern mining to detect source code improvement patterns that frequently appear in code review history. In a case study using a code review dataset of the OpenStack project, we found that the detected patterns by our proposed approach included effective examples to improve patches without reviewers' manual check. We also found that the patterns have been changed in time series; our pattern mining approach timely achieves to track the effective code improvement patterns.\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n Impact of coding style checker on code review - A case study on the openstack projects.\n \n \n \n\n\n \n Yuki Ueda; Akinori Ihara; Takashi Ishio; and Kenichi Matsumoto\n\n\n \n\n\n\n In
Proceedings - 2018 9th International Workshop on Empirical Software Engineering in Practice, IWESEP 2018, 2019. \n
\n\n
\n\n
\n\n
\n\n \n\n \n \n doi\n \n \n\n \n link\n \n \n\n bibtex\n \n\n \n \n \n abstract \n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n \n \n\n\n\n
\n
@inproceedings{\n title = {Impact of coding style checker on code review - A case study on the openstack projects},\n type = {inproceedings},\n year = {2019},\n keywords = {Code-Review,Maintainability,Source-Code-Analysis,Source-Code-Understanding},\n id = {2013f4c9-2b32-3e8f-be39-3c743c383893},\n created = {2022-08-02T01:01:28.425Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-19T05:40:10.376Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Code review is key to ensuring the absence of potential issues in source code. Code review is changing from a costly manual check by reviewer to a cost-efficient automatic check by coding style checkers. So that patch authors can verify the changed code before submitting their patches. Although cost-efficiency, the checkers do not detect all potential issues, requiring reviewers to verify the submitted patches based on their knowledge. It would be most efficient if patch authors will learn potential issues and remove the same type of issues from patches prior to code review. This study investigates potential issues that patch authors have repeatedly introduced in their patch submissions despite receiving feedback. To understand the impact of adopting checkers to patch authors' coding style improvement, this study compares two types of potential issues: Automatically Detected Issues by checkers (ADIs) and Manually Detected Issues by reviewers (MDIs). In a case study using an OpenStack code review dataset, we found that the patch authors have repeatedly introduced the same type of MDIs, while they do not repeat ADIs. This result suggests that the introduction of code style checkers might promote the patch authors' effective potential issues learning.},\n bibtype = {inproceedings},\n author = {Yuki Ueda, undefined and Akinori Ihara, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/IWESEP.2018.00014},\n booktitle = {Proceedings - 2018 9th International Workshop on Empirical Software Engineering in Practice, IWESEP 2018}\n}
\n
\n\n\n
\n Code review is key to ensuring the absence of potential issues in source code. Code review is changing from a costly manual check by reviewer to a cost-efficient automatic check by coding style checkers. So that patch authors can verify the changed code before submitting their patches. Although cost-efficiency, the checkers do not detect all potential issues, requiring reviewers to verify the submitted patches based on their knowledge. It would be most efficient if patch authors will learn potential issues and remove the same type of issues from patches prior to code review. This study investigates potential issues that patch authors have repeatedly introduced in their patch submissions despite receiving feedback. To understand the impact of adopting checkers to patch authors' coding style improvement, this study compares two types of potential issues: Automatically Detected Issues by checkers (ADIs) and Manually Detected Issues by reviewers (MDIs). In a case study using an OpenStack code review dataset, we found that the patch authors have repeatedly introduced the same type of MDIs, while they do not repeat ADIs. This result suggests that the introduction of code style checkers might promote the patch authors' effective potential issues learning.\n
\n\n\n
\n\n\n
\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n An Analysis of Computational Thinking to Implement Scratch Programs.\n \n \n \n\n\n \n Ryota Ando; and Akinori Ihara\n\n\n \n\n\n\n
International Workshop on Empirical Software Engineering in Practice. 12 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {An Analysis of Computational Thinking to Implement Scratch Programs},\n type = {article},\n year = {2019},\n month = {12},\n day = {13},\n id = {784c6c03-407a-37b3-94df-92bd9aacdfc6},\n created = {2022-08-02T06:08:58.845Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-02T06:08:58.845Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Ryota Ando, undefined and Akinori Ihara, undefined},\n journal = {International Workshop on Empirical Software Engineering in Practice}\n}
\n
\n\n\n\n
\n\n\n \n\n\n
\n
\n\n \n \n \n \n \n オープンソースソフトウェア開発者の活動量予測モデル.\n \n \n \n\n\n \n 小口 知希; 伊原 彰紀; and 稲垣 智宏\n\n\n \n\n\n\n
第26回ソフトウェア工学の基礎ワークショップ. 11 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {オープンソースソフトウェア開発者の活動量予測モデル},\n type = {article},\n year = {2019},\n month = {11},\n day = {29},\n id = {7fcd6391-59ba-357d-ae12-e1e6ba405fd4},\n created = {2022-08-02T06:09:00.771Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-02T06:09:00.771Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {小口 知希, undefined and 伊原 彰紀, undefined and 稲垣 智宏, undefined},\n journal = {第26回ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n 学習期間と予測期間による不具合報告数予測モデルの精度評価.\n \n \n \n\n\n \n 稲垣 智宏; and 伊原 彰紀\n\n\n \n\n\n\n
第26回ソフトウェア工学の基礎ワークショップ. 11 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {学習期間と予測期間による不具合報告数予測モデルの精度評価},\n type = {article},\n year = {2019},\n month = {11},\n day = {29},\n id = {f4e89087-4d38-358e-8421-566eef3b791a},\n created = {2022-08-02T06:09:01.706Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-02T06:09:01.706Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {稲垣 智宏, undefined and 伊原 彰紀, undefined},\n journal = {第26回ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n 🏆[Award]🏆コンピュテーショナル・シンキングスキルに基づくScratchプログラムの特徴分析.\n \n \n \n\n\n \n 安東 亮汰; and 伊原 彰紀\n\n\n \n\n\n\n
情報処理学会関西支部支部大会. 9 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {🏆[Award]🏆コンピュテーショナル・シンキングスキルに基づくScratchプログラムの特徴分析},\n type = {article},\n year = {2019},\n month = {9},\n day = {23},\n id = {1013195d-6f61-3014-8547-a56003b45c88},\n created = {2022-08-02T06:09:02.662Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-26T06:00:40.171Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {安東 亮汰, undefined and 伊原 彰紀, undefined},\n journal = {情報処理学会関西支部支部大会}\n}
\n
\n\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n 🏆[Award]🏆プルリクエストにおける開発者の変更提案の分類.\n \n \n \n\n\n \n 福元 春輝; and 伊原 彰紀\n\n\n \n\n\n\n
情報処理学会関西支部支部大会. 9 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {🏆[Award]🏆プルリクエストにおける開発者の変更提案の分類},\n type = {article},\n year = {2019},\n month = {9},\n day = {23},\n id = {62c4a3c6-2c15-349e-96ce-122cf3334923},\n created = {2022-08-02T06:09:03.594Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-26T06:01:30.318Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {福元 春輝, undefined and 伊原 彰紀, undefined},\n journal = {情報処理学会関西支部支部大会}\n}
\n
\n\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n Scratchプログラムにおける類似コードの特定にむけて.\n \n \n \n\n\n \n 安東 亮汰; and 伊原 彰紀\n\n\n \n\n\n\n
情報処理学会第81回全国大会. 3 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {Scratchプログラムにおける類似コードの特定にむけて},\n type = {article},\n year = {2019},\n month = {3},\n day = {16},\n id = {1ca910ac-a213-3450-8fa2-6d7ddf5ee066},\n created = {2022-08-02T06:09:04.687Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-02T06:09:04.687Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {安東 亮汰, undefined and 伊原 彰紀, undefined},\n journal = {情報処理学会第81回全国大会}\n}
\n
\n\n\n\n
\n\n\n
\n
\n\n \n \n \n \n \n コードレビューにおいて検出可能なプログラム課題の分析.\n \n \n \n\n\n \n 福元 春輝; and 伊原 彰紀\n\n\n \n\n\n\n
情報処理学会第81回全国大会. 3 2019.\n
\n\n
\n\n
\n\n
\n\n \n\n \n\n \n link\n \n \n\n bibtex\n \n\n \n\n \n\n \n \n \n \n \n \n \n\n \n \n \n\n\n\n
\n
@article{\n title = {コードレビューにおいて検出可能なプログラム課題の分析},\n type = {article},\n year = {2019},\n month = {3},\n day = {16},\n id = {e4de8fbd-9c79-30bf-9217-dcd6b0de6df5},\n created = {2022-08-02T06:09:05.664Z},\n file_attached = {false},\n profile_id = {b3dfde71-3d8d-3b4f-b54d-dcc8724cac78},\n group_id = {3650ff00-822e-3f59-b76b-d65b3771120a},\n last_modified = {2022-08-02T06:09:05.664Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {福元 春輝, undefined and 伊原 彰紀, undefined},\n journal = {情報処理学会第81回全国大会}\n}
\n
\n\n\n\n
\n\n\n\n\n\n