Published Papers - IHARA Akinori

自動生成されたパッチがコーディング規約に与える影響の分析

野口優輝, 木村祐太, 伊原彰紀, 大平雅雄

情報処理学会論文誌     2025.01  [Refereed]

Detecting Software Library Version with Backward Compatibility Loss based on Test Code Changes

Akinori Ihara, Daiki Maekawa, Kazuki Matsuda （Part： Lead author,　Corresponding author )

情報処理学会論文誌     2025  [Refereed]

相関関係の効率的な解釈を支援するための遅延相関分析手法の拡張：プロジェクト管理への活用に向けた適用実験

市井誠, 堀口日向, 柏祐太郎, 川上真澄, 伊原彰紀, 大平雅雄

情報処理学会論文誌   64 ( 7 )   2023.07  [Refereed]

Predicting Proficiency Level for Scratch Users Based on Computational Thinking

Ryota Ando, Akinori Ihara （Part： Corresponding author )

情報処理学会論文誌   63 ( 4 ) 928 - 937   2022.04  [Refereed]

Code Reviews With Divergent Review Scores: An Empirical Study of the OpenStack and Qt Communities

Toshiki Hirao, Shane McIntosh, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

IEEE Transactions on Software Engineering ( Institute of Electrical and Electronics Engineers ({IEEE}) )  48 ( 1 ) 69 - 81   2022.01  [Refereed]

DOI

SōjiTantei: Function-Call Reachability Detection of Vulnerable Code for npm Packages.

Bodin Chinthanet, Raula Gaikovina Kula, Rodrigo Eliza Zapata, Takashi Ishio, Kenichi Matsumoto, Akinori Ihara

IEICE Transactions on Information and Systems   105 ( 1 ) 19 - 20   2022.01  [Refereed]

DOI

Linkage of Similar Code Snippets Assessed in the Micro Benchmark Service jsPerf.

Kazuya Saiki, Akinori Ihara （Part： Corresponding author )

Proceedings of the International Working Conference on Source Code Analysis and Manipulation (SCAM)     247 - 251   2021.09  [Refereed]

DOI

Early Identification of Active Developers Based on their Past Contributions in OSS Projects.

Tomoki Koguchi, Akinori Ihara （Part： Corresponding author )

22nd IEEE/ACIS International Fall Virtual Conference on SoftwareEngineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD)     230 - 235   2021.09  [Refereed]

DOI

Lags in the release, adoption, and propagation of npm vulnerability fixes.

Bodin Chinthanet, Raula Gaikovina Kula, Shane McIntosh, Takashi Ishio, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

Journal of Empirical Software Engineering   26 ( 3 ) 47 - 47   2021.03  [Refereed]

DOI

ソフトウェアオープン化時代に向けたソースコード自動検証技術の開発

伊原彰紀 （Part： Lead author )

テレコム先端技術研究支援センター 技術情報誌TELECOM FRONTIER     1 - 4   2020.08  [Invited]

Analysis of Prevalent Code Improvements through Code Review

上田裕己, 石尾隆, 伊原彰紀, 松本健一 （Part： Corresponding author )

コンピュータソフトウェア   37 ( 2 )   2020.05  [Refereed]

Understanding Developer Commenting in Code Reviews

Toshiki Hirao, Raula Gaikovina Kula, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

IEICE Transactions on Information and Systems   E102-D ( 12 ) 2423 - 2432   2019.12  [Refereed]

DOI

The Review Linkage Graph for Code Review Analytics

Hirao Toshiki, McIntosh Shane, Ihara Akinori, Matsumoto Kenichi （Part： Corresponding author )

Proceedings of the 27th ACM Joint Meeting On European Software Engineering Conference And Symposium on the Foundations of Software Engineering     578 - 589   2019.08  [Refereed]

DOI

Identifying and predicting key features to support bug reporting.

Md. Rejaul Karim, Akinori Ihara, Eunjong Choi, Hajimu Iida （Part： Corresponding author )

Journal of Software Evolution and Process   31 ( 12 ) 1 - 24   2019.05  [Refereed]

DOI

Impact of coding style checker on code review - A case study on the openstack projects

Yuki Ueda, Akinori Ihara, Takashi Ishio, Kennichi Matsumoto （Part： Corresponding author )

Proceedings - 2018 9th International Workshop on Empirical Software Engineering in Practice, IWESEP 2018 ( Institute of Electrical and Electronics Engineers Inc. )    31 - 36   2019.03  [Refereed]

　View Summary

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.

DOI

On The Lag of Library Vulnerability Updates: An Investigation into the Repackage and Delivery of Security Fixes Within The npm JavaScript Ecosystem.

Bodin Chinthanet, Raula Gaikovina Kula, Takashi Ishio, Akinori Ihara, Kenichi Matsumoto

CoRR   abs/1907.03407   2019  [Refereed]

Mining Source Code Improvement Patterns from Similar Code Review Works

Ueda Yuki, Ishio Takashi, Ihara Akinori, Matsumoto Kenichi （Part： Corresponding author )

2019 IEEE 13TH INTERNATIONAL WORKSHOP ON SOFTWARE CLONES (IWSC '19)     13 - 19   2019  [Refereed]

The Impact of Human Factors on the Participation Decision of Reviewers in Modern Code Review.

Shade Ruangwan, Patanamon Thongtanunam, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

Journal of Empirical Software Engineering   24 ( 2 ) 973 - 1016   2019  [Refereed]

What Are the Perception Gaps Between FLOSS Developers and SE Researchers? A Case of Bug Finding Research

Yutaro Kashiwa, Akinori Ihara, Masao Ohira （Part： Corresponding author )

Proceedings of the International Conference on Open Source Systems (OSS) 2019 ( SPRINGER INTERNATIONAL PUBLISHING AG )  556   44 - 57   2019  [Refereed]

　View Summary

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.

DOI

An Empirical Study of README contents for JavaScript Packages.

Shohei Ikeda, Akinori Ihara, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

IEICE Transactions on Information and Systems   102-D ( 2 ) 280 - 288   2019  [Refereed]

DOI

Do review feedbacks influence to a contributor's time spent on oss projects?

Takuto Norikane, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

Proceedings - 2018 IEEE/ACIS 3rd International Conference on Big Data, Cloud Computing, Data Science and Engineering, BCD 2018 ( Institute of Electrical and Electronics Engineers Inc. )    109 - 113   2018.11  [Refereed]

　View Summary

Open Source Software (OSS) does not work without contributions from the community. In particular, long-term contributors (LTCs) (e.g., committer), defined as contributors who spend at least one year on OSS projects, play a crucial role in a project success because they would have permission to add (commit) code changes to a project's version control system, and to become a mentor for a beginner in OSS projects. However, contributors often leave a project before becoming a LTC because most contributors are volunteers. If contributors are motivated in their work in OSS projects, they might not leave the projects. In this study, we examine the phenomena involved in becoming a LTC in terms of motivation to continue in OSS projects. In particular, our target motivation is to understand what is involved in long-term contribution with other expert contributors. We study classifier to identify a LTC who will contribute patch submissions for more than one year based on collaboration in terms of the code review process. In detail, we analyze what review feedbacks encourage a contributor to continue with OSS project. Using a Qt project dataset, we build a prediction model to identify a LTC. We find that not only contributor's activities, but also a reviewer feedbacks, useful in identifying LTCs.

DOI

How are IF-Conditional Statements Fixed Through Peer CodeReview?

Yuki Ueda, Akinori Ihara, Takashi Ishio, Toshiki Hirao, Kenichi Matsumoto （Part： Corresponding author )

IEICE Transactions on Information and Systems   101-D ( 11 ) 2720 - 2729   2018.11  [Refereed]

DOI

An empirical study of design discussions in code review

Farida El Zanaty, Toshiki Hirao, Shane McIntosh, Akinori Ihara, Kenichi Matsumoto

International Symposium on Empirical Software Engineering and Measurement ( IEEE Computer Society )    2018.10

　View Summary

Background: Code review is a well-established software quality practice where developers critique each others' changes. A shift towards automated detection of low-level issues (e.g., integration with linters) has, in theory, freed reviewers up to focus on higher level issues, such as software design. Yet in practice, little is known about the extent to which design is discussed during code review. Aim: To bridge this gap, in this paper, we set out to study the frequency and nature of design discussions in code reviews. Method: We perform an empirical study on the code reviews of the OpenStack Nova (provisioning management) and Neutron (networking abstraction) projects. We manually classify 2,817 review comments from a randomly selected sample of 220 code reviews. We then train and evaluate classifiers to automatically label review comments as design related or not. Finally, we apply the classifiers to a larger sample of 2,506,308 review comments to study the characteristics of reviews that include design discussions. Results: Our manual analysis indicates that (1) design discussions are still quite rare, with only 9% and 14% of Nova and Neutron review comments being related to software design, respectively
and (2) design feedback is often constructive, with 73% of the design-related comments also providing suggestions to address the concerns. Furthermore, our classifiers achieve a precision of 59%-66% and a recall of 70%-78%, outperforming baselines like zeroR by 43 percentage points in terms of F1-score. Finally, code changes that have design-related feedback have a statistically significantly increased rate of abandonment (Pearson 2 test, DF=1, p &lt
0.001). Conclusion: Design-related discussion during code review is still rare. Since design discussion is a primary motivation for conducting code review, more may need to be done to encourage such discussions among contributors.

DOI

Extraction of library update history using source code reuse detection

Kanyakorn Jewmaidang, Takashi Ishio, Akinori Ihara, Kenichi Matsumoto, Pattara Leelaprute

IEICE Transactions on Information and Systems ( Institute of Electronics, Information and Communication, Engineers, IEICE )  E101D ( 3 ) 799 - 802   2018.06  [Refereed]

　View Summary

This paper proposes a method to extract and visualize a library update history in a project. The method identifies reused library versions by comparing source code in a product with existing versions of the library so that developers can understand when their own copy of a library has been copied, modified, and updated.

DOI

Extraction of Library Update History Using Source Code Reuse Detection(vol 101, pg 799, 2018)

Jewmaidang Kanyakorn, Ishio Takashi, Ihara Akinori, Matsumoto Kenichi

IEICE TRANSACTIONS ON INFORMATION AND SYSTEMS   E101D ( 6 ) 1722   2018.06  [Refereed]

DOI

A Predicting Method of Issue-fixing Time Using Development Metrics in OSS Projects

伊原彰紀, 若元亮樹, 松本健一 （Part： Lead author,　Corresponding author )

情報処理学会論文誌   59 ( 3 ) 834 - 844   2018  [Refereed]

Towards Smoother Library Migrations: A Look at Vulnerable Dependency Migrations at Function Level for npm JavaScript Packages.

Rodrigo Elizalde Zapata, Raula Gaikovina Kula, Bodin Chinthanet, Takashi Ishio, Kenichi Matsumoto, Akinori Ihara

Proceedings of the IEEE International Conference on Software Maintenance and Evolution (ICSME) 2018 ( IEEE Computer Society )    559 - 563   2018  [Refereed]

DOI

An Empirical Study on README contents for JavaScript Packages.

Shohei Ikeda, Akinori Ihara, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

IEICE Transactions on Information and Systems   abs/1802.08391   2018  [Refereed]

An Politeness Analysis for Understanding Continuous Activities of Developers in OSS Communities

宮崎智己, 伊原彰紀, 大平雅雄, 東裕之輔, 山谷陽亮 （Part： Corresponding author )

情報処理学会論文誌   59 ( 1 ) 2 - 11   2018  [Refereed]

The impact of IR-based classifier configuration on the performance and the effort of method-level bug localization

Chakkrit Tantithamthavorn, Surafel Lemma Abebe, Ahmed E. Hassan, Akinori Ihara, Kenichi Matsumoto

Information and Software Technology ( Elsevier B.V. )  102   160 - 174   2018  [Refereed]

　View Summary

Context: IR-based bug localization is a classifier that assists developers in locating buggy source code entities (e.g., files and methods) based on the content of a bug report. Such IR-based classifiers have various parameters that can be configured differently (e.g., the choice of entity representation). Objective: In this paper, we investigate the impact of the choice of the IR-based classifier configuration on the top-k performance and the required effort to examine source code entities before locating a bug at the method level. Method: We execute a large space of classifier configuration, 3172 in total, on 5266 bug reports of two software systems, i.e., Eclipse and Mozilla. Results: We find that (1) the choice of classifier configuration impacts the top-k performance from 0.44% to 36% and the required effort from 4395 to 50,000 LOC
(2) classifier configurations with similar top-k performance might require different efforts
(3) VSM achieves both the best top-k performance and the least required effort for method-level bug localization
(4) the likelihood of randomly picking a configuration that performs within 20% of the best top-k classifier configuration is on average 5.4% and that of the least effort is on average 1%
(5) configurations related to the entity representation of the analyzed data have the most impact on both the top-k performance and the required effort
and (6) the most efficient classifier configuration obtained at the method-level can also be used at the file-level (and vice versa). Conclusion: Our results lead us to conclude that configuration has a large impact on both the top-k performance and the required effort for method-level bug localization, suggesting that the IR-based configuration settings should be carefully selected and the required effort metric should be included in future bug localization studies.

DOI

Maintaining third-party libraries through domain-specific category recommendations.

Daiki Katsuragawa, Akinori Ihara, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

Proceedings of the 1st International Workshop on Software Health (SoHeal) 2018 ( ACM )    2 - 9   2018  [Refereed]

An Analysis of Library Rollbacks: A Case Study of Java Libraries

Hirohiko Suwa, Akinori Ihara, Raula Gaikovina Kula, Daiki Fujibayashi, Kenichi Matsumoto

1st International Workshop on Software-driven Big Data Analytics     2017.12  [Refereed]

DOI

How is if statement fixed through code review? A case study of QT project

Yuki Ueda, Akinori Ihara, Toshiki Hirao, Takashi Ishio, Kenichi Matsumoto （Part： Corresponding author )

Proceedings - 2017 IEEE 28th International Symposium on Software Reliability Engineering Workshops, ISSREW 2017 ( Institute of Electrical and Electronics Engineers Inc. )    207 - 213   2017.11  [Refereed]

　View Summary

Peer code review is key to ensuring the absence of software defects. To improve the review process, many code review tools provide OSS(Open Source Software) project CI(Continuous Integration) tests that automatically verify code quality issues such as a code convention issues. However, these tests do not cover project policy issues and a code readability issues. In this study, our main goal is to understand how a code owner fixes conditional statement issues based on reviewers feedback. We conduct an empirical study to understand if statement changes after review. Using 69,325 review requests in the Qt project, we analyze changes of the if conditional statements that (1) are requested to be reviewed, and (2) that are implemented after review. As a result, we find the most common symbolic changes are '(' and ')' (35%), '!' operator (20%) and '-&gt
' operator (12%). Also, '!' operator is frequently replaced with '(' and ')'.

DOI

Understanding key features of high-impact bug reports

Md. Rejaul Karim, Akinori Ihara, Xin Yang, Hajimu Iida, Kenichi Matsumoto （Part： Corresponding author )

Proceedings - 8th IEEE International Workshop on Empirical Software Engineering in Practice, IWESEP 2017 ( Institute of Electrical and Electronics Engineers Inc. )    53 - 58   2017.05  [Refereed]

　View Summary

Nowadays, software projects are receiving bug reports on a daily basis. Developers cannot treat all the bugs in the same priority since some bugs can significantly affect software development process and the quality of products. Previous studies defined these bugs as High Impact Bug (HIB) and they found that HIB should be fixed quicker than other bugs in software development. However, fixing a HIB sometimes become complicated because the low-quality bug reports can be delay the bug fixing. In this study, we investigate what information is essential when reporting a HIB report. As a case study, we manually examine the HIB reports and perform both qualitative and quantitative analysis in Apache Camel project. Our main findings include: (1) we find four types of features are the most requested information from developers when they fix HIB, (2) the requested additional information significantly influences bug fixing time.

DOI

Which review feedback did long-term contributors get on OSS projects?

Takuto Norikane, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering ( Institute of Electrical and Electronics Engineers Inc. )    571 - 572   2017.03  [Refereed]

　View Summary

Open Source Software (OSS) cannot exist without contributions from the community. In particular, long-term contributors (LTCs) (e.g., committer), defined as contributors who spend at least one year on OSS projects, play crucial role in a project success because they would have permission to add (commit) code changes to a project's version control system, and to become a mentor for a beginner in OSS projects. However, contributors often leave a project before becoming a LTC because most contributors are volunteers. If contributors are motivated in their work in OSS projects, they might not leave the projects. In this study, we examine the phenomena involved in becoming a LTC in terms of motivation to continue in OSS projects. In particular, our target motivation is to understand what is involved in long-term contribution with other expert contributors. We study classifier to identify a LTC who will contribute patch submissions for more than one year based on collaboration in terms of the code review process. In detail, we analyze what review feedbacks encourage a contributor to continue with OSS project. Using a Qt project dataset, we understand review feedback which affected contribution period of the developer.

DOI

Does the release cycle of a library project influence when it is adopted by a client project?

Daiki Fujibayashi, Akinori Ihara, Hirohiko Suwa, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Corresponding author )

SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering ( Institute of Electrical and Electronics Engineers Inc. )    569 - 570   2017.03  [Refereed]

　View Summary

A key goal of this research is to understand the relationship between adoption of software library versions and its release cycle. In detail, we conducted an empirical study of the release cycle of 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our preliminary findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle.

DOI

Toward Identifying a Re-opened Bug Based on Reviewers Disagreement―Case Study of OpenStack Project

林 宏徳, 伊原 彰紀, 松本 健一 （Part： Corresponding author )

情報処理学会論文誌 ( 情報処理学会 )  58 ( 3 ) 721 - 725   2017.03  [Refereed]

Understanding when to adopt a library: A case study on ASF projects

Akinori Ihara, Daiki Fujibayashi, Hirohiko Suwa, Raula Gaikovina Kula, Kenichi Matsumoto （Part： Lead author,　Corresponding author )

Proceedings of the International Conference on Open Source Systems (OSS) ( Springer New York LLC )  496   128 - 138   2017  [Refereed]

　View Summary

Software libraries are widely used by both industrial and open source client projects. Ideally, a client user of a library should adopt the latest version that the library project releases. However, sometimes the latest version is not better than a previous version. This is because the latest version may include additional developer effort to test and integrate all changed features. In this study, our main goal is to better understand the relationship between adoption of library versions and its release cycle. Specifically, we conducted an empirical study of release cycles for 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles.

DOI

Project IŜ3: Incentive-based intelligent intervention for smart and sustainable society

Yutaka Arakawa, Keiichi Yasumoto, Kenichi Matsumoto, Hideaki Hata, Hirohiko Suwa, Akinori Ihara, Manato Fujimoto

Proceedings - 2016 5th IIAI International Congress on Advanced Applied Informatics, IIAI-AAI 2016     215 - 218   2016.08  [Refereed]

　View Summary

© 2016 IEEE. Project IS^3 is the leading-edge project in Nara Institute of Science and Technology, a national graduate school in Japan, started from February 2016. This project aims to utilize a human's behavior change for solving the social problems and maintaining our society sustainably. In order to cause the behavior change intentionally, various information technologies are required. In this paper, we explain the concept and goal of our project and figure out what we will do in this project.

DOI

Toward selecting a reliable version of OSS library based on bug-fixing curve

Keisuke Fujino, Akinori Ihara, Kiyoshi Honda, Hironori Washizaki, Kenichi Matsumoto （Part： Corresponding author )

23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016)     2016.03  [Refereed]

Treemap Forest : An Exploratory Data Visualization Approach for Software Development Project Datasets

中川 尊雄, 伊原 彰紀, 松本 健一 （Part： Corresponding author )

SEC journal ( 情報処理推進機構技術本部ソフトウェア・エンジニアリング・センター )  12 ( 1 ) 8 - 15   2016  [Refereed]

Open Source Software Engineering.

伊原彰紀, 大平雅雄 （Part： Lead author,　Corresponding author )

コンピュータソフトウェア ( 日本ソフトウェア科学会 )  33 ( 1 ) 1_28 - 1_40   2016  [Refereed]

A Study of Redundant Metrics in Defect Prediction Datasets

Jirayus Jiarpakdee, Chakkrit Tantithamthavorn, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

2016 IEEE 27TH INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING WORKSHOPS (ISSREW) ( IEEE )    51 - 52   2016  [Refereed]

　View Summary

Defect prediction models can help Software Quality Assurance (SQA) teams understand their past pitfalls that lead to defective modules. However, the conclusions that are derived from defect prediction models without mitigating redundant metrics issues may be misleading. In this paper, we set out to investigate if redundant metrics issues are affecting defect prediction studies, and its degree and causes of redundancy. Through a case study of 101 publicly-available defect datasets of systems that span both proprietary and open source domains, we observe that (1) 10%-67% of metrics of the studied defect datasets are redundant, and (2) the redundancy of metrics has to do with the aggregation functions of metrics. These findings suggest that researchers should be aware of redundant metrics prior to constructing a defect prediction model in order to maximize internal validity of their studies.

DOI

Code Review Participation: Game Theoretical Modeling of Reviewers in Gerrit Datasets

Norihito Kitagawa, Hideaki Hata, Akinori Ihara, Kiminao Kogiso, Kenichi Matsumoto

9TH IEEE/ACM INTERNATIONAL WORKSHOP ON COOPERATIVE AND HUMAN ASPECTS OF SOFTWARE ENGINEERING (CHASE 2016) ( IEEE )    64 - 67   2016  [Refereed]

　View Summary

Code review is a common practice for improving the quality of source code changes and expediting knowledge transfer in a development community. In modern code review, source code changes or patches are considered to be assessed and approved for integration by multiple reviews. However, from our empirical study, we found that some patches are reviewed by only one reviewer, and some reviewers did not continue the review discussion, which can have negative effects on software quality. To understand these reviewers' behaviors, we model the code review situation based on the snowdrift game, which is used to analyze social dilemmas. With this game-theoretical modeling, we found that it can explain reviewers' behaviors well.

DOI

Understanding Question Quality through Affective Aspect in Q&A Site

Jirayus Jiarpakdee, Akinori Ihara, Ken-ichi Matsumoto （Part： Corresponding author )

2016 IEEE/ACM 1ST INTERNATIONAL WORKSHOP ON EMOTION AWARENESS IN SOFTWARE ENGINEERING (SEMOTION) ( IEEE )    12 - 17   2016  [Refereed]

　View Summary

Ever since the Internet has become widely available, question and answer sites have been used as a knowledge sharing service. Users ask the community about how to solve problems, hoping that there will be someone to provide a solution. However, not every question is answered. Eric Raymond claimed that how an user asks a question is important. Existing studies have presented ways to study the question quality by textual, community-based or affective features. In this paper, we investigated how affective features are related to the question quality, and we found that using affective features improves the prediction of question quality. Moreover, Favorite Vote Count feature has the highest influence on our prediction models.

DOI

The Impact of a Low Level of Agreement Among Reviewers in a Code Review Process

Toshiki Hirao, Akinori Ihara, Yuki Ueda, Passakorn Phannachitta, Ken-ichi Matsumoto （Part： Corresponding author )

OPEN SOURCE SYSTEMS: INTEGRATING COMMUNITIES, OSS 2016 ( SPRINGER-VERLAG BERLIN )  472   97 - 110   2016  [Refereed]

　View Summary

Software code review systems are commonly used in software development. In these systems, many patches are submitted to improve the quality. To verify the quality, voting is commonly used by contributors; however, there still exists a major problem, namely, that reviewers do not always simply reach a broad agreement. In our previous study, we found that consensus is not usually reached, implying that an individual reviewer's final decision usually differs from that of the majority of the other reviewers. In this study, we further investigate the reasons why such situations often occur, and provide suggestions for better handling of these problems. Our analysis of the Qt and OpenStack project datasets allow us to suggest that a patch owner should select more appropriate reviewers who often agree with others' decisions.

DOI

The Impact of Mislabelling on the Performance and Interpretation of Defect Prediction Models

Chakkrit Tantithamthavorn, Shane McIntosh, Ahmed E. Hassan, Akinori Ihara, Kenichi Matsumoto （Part： Corresponding author )

Proceedings of the IEEE/ACM 37th IEEE International Conference on Software Engineering 2015 ( IEEE )    812 - 823   2015  [Refereed]

　View Summary

The reliability of a prediction model depends on the quality of the data from which it was trained. Therefore, defect prediction models may be unreliable if they are trained using noisy data. Recent research suggests that randomly-injected noise that changes the classification (label) of software modules from defective to clean (and vice versa) can impact the performance of defect models. Yet, in reality, incorrectly labelled (i.e., mislabelled) issue reports are likely non-random. In this paper, we study whether mislabelling is random, and the impact that realistic mislabelling has on the performance and interpretation of defect models. Through a case study of 3,931 manually-curated issue reports from the Apache Jackrabbit and Lucene systems, we find that: (1) issue report mislabelling is not random; (2) precision is rarely impacted by mislabelled issue reports, suggesting that practitioners can rely on the accuracy of modules labelled as defective by models that are trained using noisy data; (3) however, models trained on noisy data typically achieve 56%-68% of the recall of models trained on clean data; and (4) only the metrics in top influence rank of our defect models are robust to the noise introduced by mislabelling, suggesting that the less influential metrics of models that are trained on noisy data should not be interpreted or used to make decisions.

DOI

A Data Mining Method for Understanding Co-evolution of OSS Systems and Communities

山谷陽亮, 大平雅雄, PHANNACHITTA Passakorn, 伊原彰紀

情報処理学会論文誌 ( 一般社団法人情報処理学会 )  56 ( 1 ) 59 - 71   2015  [Refereed]

A Dataset of High Impact Bugs: Manually-Classified Issue Reports

Masao Ohira, Yutaro Kashiwa, Yosuke Yamatani, Hayato Yoshiyuki, Yoshiya Maeda, Nachai Limsettho, Keisuke Fujino, Hideaki Hata, Akinori Ihara, Kenichi Matsumoto

Proceedings of the 12th Working Conference on Mining Software Repositories 2015 ( IEEE )  2015-August   518 - 521   2015  [Refereed]

　View Summary

The importance of supporting test and maintenance activities in software development has been increasing, since recent software systems have become large and complex. Although in the field of Mining Software Repositories (MSR) there are many promising approaches to predicting, localizing, and triaging bugs, most of them do not consider impacts of each bug on users and developers but rather treat all bugs with equal weighting, excepting a few studies on high impact bugs including security, performance, blocking, and so forth. To make MSR techniques more actionable and effective in practice, we need deeper understandings of high impact bugs. In this paper we introduced our dataset of high impact bugs which was created by manually reviewing four thousand issue reports in four open source projects (Ambari, Camel, Derby and Wicket).

DOI

Toward Monitoring Bugs-fixing Process after the Releases in Open Source Software

Keisuke Fujino, Akinori Ihara, Kiyoshi Honda, Hironori Washizaki, Kenichi Matsumoto （Part： Corresponding author )

6th International Workshop on Empirical Software Engineering in Practice (IWESEP 2014)     2014.11  [Refereed]

Adaptive Search Framework: Better Search Result for Community

Papon Yongpisanpop, Masao Ohira, Akinori Ihara, Kenichi Matsumoto

情報社会学会誌   8 ( 2 ) 29 - 43   2014.03  [Refereed]

Impact Analysis of Granularity Levels on Feature Location Technique

Chakkrit Tantithamthavorn, Akinori Ihara, Hideaki Hata, Kenichi Matsumoto

Communications in Computer and Information Science ( Springer )  432 CCIS   135 - 149   2014  [Refereed]

　View Summary

Due to the increasing of software requirements and software features, modern software systems continue to grow in size and complexity. Locating source code entities that required to implement a feature in millions lines of code is labor and cost intensive for developers. To this end, several studies have proposed the use of Information Retrieval (IR) to rank source code entities based on their textual similarity to an issue report. The ranked source code entities could be at a class or function granularity level. Source code entities at the class-level are usually large in size and might contain a lot of functions that are not implemented for the feature. Hence, we conjecture that the class-level feature location technique requires more effort than function-level feature location technique. In this paper, we investigate the impact of granularity levels on a feature location technique. We also presented a new evaluation method using effort-based evaluation. The results indicated that function-level feature location technique outperforms class-level feature location technique. Moreover, function-level feature location technique also required 7 times less effort than class-level feature location technique to localize the first relevant source code entity. Therefore, we conclude that feature location technique at the function-level of program elements is effective in practice. © Springer-Verlag Berlin Heidelberg 2014.

DOI

Early Identification of Future Committers in Open Source Software Projects

Akinori Ihara, Yasutaka Kamei, Masao Ohira, Ahmed E. Hassan, Naoyasu Ubayashi, Ken-ichi Matsumoto

2014 14TH INTERNATIONAL CONFERENCE ON QUALITY SOFTWARE (QSIC 2014) ( IEEE COMPUTER SOC )    47 - 56   2014  [Refereed]

　View Summary

There exists two types of developers in Open Source Software (OSS) projects: 1) Committers who have permission to commit edited source code to the Version Control System (VCS), 2) Developers who contribute source code but cannot commit to the VCS directly. In order to develop and evolve high quality OSS, projects are always in search of new committers. OSS projects often promote strong developers to become committers. When existing committers find strong developers, they propose their promotion to a committer role. Delaying the committer-promotion might lead to strong developers departing from an OSS project and the project losing them. However early committer-promotion comes with its own slew of risks as well (e.g., the promotion of inexperienced developers). Hence, committer-promotion decisions are critical for the quality and successful evolution of OSS projects. In this paper, we examine the committer-promotion phenomena for two OSS projects (Eclipse and Firefox). We find that the amount of activities by future committers was higher than the amount of activities by developers who did not become committers). We also find that some developers are promoted to a committer role very rapidly (within a few month) while some of developers take over one year to become a committer. Finally, we develop a committer-identification model to assist OSS projects identifying future committers.

DOI

Industry Questions About Open Source Software in Business: Research Directions and Potential Answers

Akinori Ihara, Akito Monden, Ken-ichi Matsumoto （Part： Lead author,　Corresponding author )

Proceedings of the 6th International Workshop on Empirical Software Engineering in Practice 2014 ( IEEE )    55 - 59   2014  [Refereed]

　View Summary

As open source software (OSS) has become an integral part of today's software businesses, many software companies rely on OSS to develop their customer solutions and products. On the other hand, they face various concerns in using OSS, such as technical support, quality, security and licensing issues. This paper focuses on OSS-related FAQ in industry, and tries to answer them or to provide research directions based on lessons learned from recent mining OSS repository researches.

DOI

Exploratory Data Analysis in Independent Assessment of Software Quality: A Case Study of OSS Project Data

大平 雅雄, 伊原 彰紀, 中野 大輔, 松本 健一

SEC Journal ( 情報処理推進機構 )  10 ( 1 )   2014  [Refereed]

「ソフトウェア工学の実証的アプローチ」シリーズ第5回 ソフトウェアリポジトリマイニング

門田 暁人, 伊原 彰紀, 松本 健一

コンピュウータソフトウェア   30 ( 2 ) 52 - 65   2013.05  [Refereed]

Predicting the Bug Fixing Time Based on the Bug Assignment Patterns in OSS Development

正木 仁, 大平 雅雄, 伊原 彰紀, 松本 健一

情報処理学会論文誌 ( 情報処理学会 )  54 ( 2 ) 933 - 944   2013.02  [Refereed]

　View Summary

大規模OSSプロジェクトには日々大量の不具合が報告されており，不具合修正時間（OSSプロジェクトに報告された不具合が解決するまでに要する時間）をより正確に見積もることが重要になってきている．OSSプロジェクト管理者は，次期バージョンのリリースまでにどの不具合を修正すべきかを判断しなければならないためである．しかしながら，不具合の修正範囲の大きさや問題の複雑さの違い，ボランティアを主体とする開発者のスキルセットの違いなどの要因によって，個々の不具合の修正時間を見積もることは容易ではない．そのため近年，OSS開発における不具合修正時間の予測に関する研究がさかんに行われている．本論文では，不具合割当てパターンを用いて不具合修正時間の予測モデルを構築する．不具合割当てパターンとは，不具合修正タスク割当て時の不具合報告者・管理者・修正担当者の3者の社会的関係を分類したものである．不具合割当てパターンの違いにより，修正作業にとりかかるまでの時間および修正作業自体に要する時間はそれぞれ大きく異なることが知られている．従来研究の多くは不具合情報（重要度や優先度など）に基づいて予測モデルを構築しているが，不具合管理パターンを考慮することでさらなる予測精度の向上を期待できる．本論文では，Eclipse PlatformおよびJDTを対象として構築した予測モデルの評価を行った．実験の結果，不具合割当てパターンが不具合修正時間の予測精度向上に寄与するとともに，指定期間内（1週間以内など）に不具合修正が完了するか否かの判断を支援できることが分かった．さらに，本予測モデルを利用することで，Platformで約16%，JDTで約10%多くの不具合を修正可能と判断できることが分かった．The number of reported bugs has been increasing especially in large-scale open source software (OSS) projects. Project managers in the projects have to decide which bugs should be resolved until they release the next version of their products. However it is not easy to estimate the time to resolve each bug due to the differences of the size of required modifications, the difficulty of each modification, skill set of each developer, and so forth. To address this issue, many studies have tried to predict the bug fixing time in OSS development. In this paper we constructs a prediction model for the bug fixing time, using the bug assignment patterns which have an impact on developer's performance of fixing bugs. The bug assignment patterns categorize the social relationships among bug reporters, managers, and developers in assigning bug fixing tasks. While most studies in the past only used the information extracted from bug reports itself, taking the bug assignment patterns into account would lead to prediction results with higher accuracy. Using data from the Eclipse Platform and JDT projects, we evaluates the prediction model. As a result, we found that the bug assignment patterns improved the prediction accuracy and help OSS managers make sure if a target bug will be resolved in a specified period (e.g., one week). We also found that our prediction model can contribute to resolve more bugs until the specified release (about 16% in Platform and about 10% in JDT).

Studying re-opened bugs in open source software.

Emad Shihab, Akinori Ihara, Yasutaka Kamei, Walid M. Ibrahim, Masao Ohira, Bram Adams, Ahmed E. Hassan, Ken-ichi Matsumoto

Empirical Software Engineering   18 ( 5 ) 1005 - 1042   2013  [Refereed]

DOI

Mining Software Repositories

門田暁人, 伊原彰紀, 松本健一

コンピュータソフトウェア ( 日本ソフトウェア科学会 )  30 ( 2 ) 52 - 65   2013  [Refereed]

DOI

Using Co-Change Histories to Improve Bug Localization Performance

Chakkrit Tantithamthavorn, Akinori Ihara, Ken-ichi Matsumoto

2013 14TH ACIS INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, ARTIFICIAL INTELLIGENCE, NETWORKING AND PARALLEL/DISTRIBUTED COMPUTING (SNPD 2013) ( IEEE )    543 - 548   2013  [Refereed]

　View Summary

A large open source software (OSS) project receives many bug reports on a daily basis. Bug localization techniques automatically pinpoint source code fragments that are relevant to a bug report, thus enabling faster correction. Even though many bug localization methods have been introduced, their performance is still not efficient. In this research, we improved on existing bug localization methods by taking into account co-change histories. We conducted experiments on two OSS datasets, the Eclipse SWT 3.1 project and the Android ZXing project. We validated our approach by evaluating effectiveness compared to the state-of-the-art approach BugLocator. In the Eclipse SWT 3.1 project, our approach reliably identified source code that should be fixed for a bug in 72.46% of the total bugs, while BugLocator identified only 51.02%. In the Android ZXing project, our approach identified 85.71%, while BugLocator identified 60%.

DOI

What type of thread can get feedback in oss user mailing list?

Akinori Ihara, Yuji Tsuda, Ken-Ichi Matsumoto

2013 5th International Workshop on Social Software Engineering, SSE 2013 - Proceedings     25 - 28   2013  [Refereed]

　View Summary

High quality Open Source Software (OSS) has been used in many commercial software developments. In order to provide technical support to end users, OSS projects manage a user mailing list. It is for discussion about bugs and new functions of OSS with end users. However, according to a survey of Japanese companies that use OSS to build their commercial software, the biggest problem is the lack of adequate technical support. In this study, we investigate what type of thread can get feedback in user mailing list. As a result of a case study using Apache and Python project data, a thread is posted by a deep experienced user would be received a useful answer. In addition, we found threads written about internal system information of the OSS is more likely to be replied. Copyright 2013 ACM.

DOI

Mining A Change History to Quickly Identify Bug Locations : A Case Study of the Eclipse Project

Chakkrit Tantithamthavorn, Rattamont Teekavanich, Akinori Ihara, Ken-ichi Matsumoto

2013 IEEE INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING WORKSHOPS (ISSREW) ( IEEE )    108 - 113   2013  [Refereed]

　View Summary

In this study, we proposed an approach to mine a change history to improve the bug localization performance. The key idea is that a recently fixed file may be fixed in the near future. We used a combination of textual feature and mining the change history to recommend source code files that are likely to be fixed for a given bug report. First, we adopted the Vector Space Model (VSM) to find relevant source code files that are textually similar to the bug report. Second, we analyzed the change history to identify previously fixed files. We then estimated the fault proneness of these files. Finally, we combined the two scores, from textual similarity and fault proneness, for every source code file. We then recommend developers examine source code files with higher scores. We evaluated our approach based on 1,212 bug reports from the Eclipse Platform and Eclipse JDT. The experimental results show that our proposed approach can improve the bug localization performance and effectively identify buggy files.

An Algorithm for Gradual Patch Acceptance Detection in Open Source Software Repository Mining

Passakorn Phannachitta, Akinori Ihara, Pijak Jirapiwong, Masao Ohira, Kenichi Matsumoto

IEICE Transactions on Information and Systems   E95-A ( 9 ) 1478 - 1489   2012.09  [Refereed]

Good or Bad Committers? - A Case Study of Committer's Activities on the Eclipse's Bug Fixing Process

Anakorn jongyindee, Masao Ohira, Akinori Ihara, Kenichi Matsumoto

IEICE Transactions on Information and Systems   E95-D ( 9 ) 2202 - 2210   2012.09  [Refereed]

OSS開発における不具合修正プロセスの現状と課題:不具合修正時間の短縮化へ向けた分析

伊原彰紀, 大平雅雄, 松本健一

情報社会学会誌   6 ( 2 ) 1 - 12   2012  [Refereed]

A Candidate Committer Prediction Based on Developer Activities in Open Source Software Projects

IHARA Akinori, KAMEI Yasutaka, OHIRA Masao, MATSUMOTO Ken-ichi, UBAYASHI Naoyasu

電子情報通信学会論文誌 ( 一般社団法人電子情報通信学会 )  J95-D ( 2 ) 237 - 249   2012  [Refereed]

Locating source code to be fixed based on initial bug reports - A case study on the eclipse project

Phiradet Bangcharoensap, Akinori Ihara, Yasutaka Kamei, Ken-Ichi Matsumoto

Proceedings - 2012 4th International Workshop on Empirical Software Engineering in Practice, IWESEP 2012     10 - 15   2012  [Refereed]

　View Summary

In most software development, a Bug Tracking System is used to improve software quality. Based on bug reports managed by the bug tracking system, triagers who assign a bug to fixers and fixers need to pinpoint buggy files that should be fixed. However if triagers do not know the details of the buggy file, it is difficult to select an appropriate fixer. If fixers can identify the buggy files, they can fix the bug in a short time. In this paper, we propose a method to quickly locate the buggy file in a source code repository using 3 approaches, text mining, code mining, and change history mining to rank files that may be causing bugs. (1) The text mining approach ranks files based on the textual similarity between a bug report and source code. (2) The code mining approach ranks files based on prediction of the fault-prone module using source code product metrics. (3) The change history mining approach ranks files based on prediction of the fault-prone module using change process metrics. Using Eclipse platform project data, our proposed model gains around 20% in TOP1 prediction. This result means that the buggy files are ranked first in 20% of bug reports. Furthermore, bug reports that consist of a short description and many specific words easily identify and locate the buggy file. © 2012 IEEE.

DOI

グローバル環境下におけるOSS開発者の情報交換に対する時差の影響

亀井靖高, 大平雅雄, 伊原彰紀, 小山貴和子, 松本真佑, 松本健一, 鵜林尚靖

情報社会学会誌   6 ( 2 ) 17 - 32   2012

グローバル環境下におけるOSS開発者の情報交換に対する時差の影響

亀井 靖高, 大平 雅雄, 伊原 彰紀, 小山 貴和子, 本 真佑, 松本 健一, 鵜林 尚靖

情報社会学会学会誌   6 ( 2 ) 13 - 30   2011.11  [Refereed]

An analysis of gradual patch application: A better explanation of patch acceptance

Passakorn Phannachitta, Pijak Jirapiwongy, Akinori Ihara, Masao Ohira, Ken-Ichi Matsumoto

Proceedings - Joint Conference of the 21st International Workshop on Software Measurement, IWSM 2011 and the 6th International Conference on Software Process and Product Measurement, MENSURA 2011 ( IEEE Computer Society )    106 - 115   2011  [Refereed]

　View Summary

Patch submission has been known as one of the most important activities to sustain the open source software (OSS). The patch archive can be analyzed to procure many benefit cognizance for supporting the OSS project works. The recent models and methods that analyze the patches acceptance are quite rack of comprehensive
hence, complex activities such as a committer portioning the submitted patch out and accept are still excluded from the analysis. Therefore, the results derived from those methods would be inadequate to conclude the actual patch acceptance. In this research, we introduce an algorithm for analyzing patch acceptance including the partial and gradually accepted conditions. Validating our algorithm, we present our methods for indicating the partial and gradual application of the submitted patch between either mailing list and SVN or Bugzilla and CVS which are the commonly deployed patchactivities related system. We studied on two well known OSS projects
Apache HTTP and Eclipse Platform. We obtained a fascinating conclusion that larger patches have more confident to be accepted than the smaller contradicted to other analysis that came from the recent methods. © 2011 IEEE.

DOI

Good or bad committers? A case study of committers' cautiousness and the consequences on the bug fixing process in the eclipse project

Anakorn Jongyindee, Masao Ohira, Akinori Ihara, Ken-Ichi Matsumoto

Proceedings - Joint Conference of the 21st International Workshop on Software Measurement, IWSM 2011 and the 6th International Conference on Software Process and Product Measurement, MENSURA 2011 ( IEEE Computer Society )    116 - 125   2011  [Refereed]

　View Summary

There are many roles to play in the bug fixing process in open source software development. A developer called "Committer", who has a permission to submit a patch into software repository, plays a major role in this process and hold a key to the successfulness of the project. In this work, we have observed each committer activities from the Eclipse-Platform bug tracking system and version archives. Despite the importance of committer's activities, we suspected that sometimes committers can make mistakes, which have negative consequences to the bug fixing process. Our research focus on studying the consequences of each committer's activities to this process. We collected each committer's historical data and evaluated each of them by comparing the more cautiousness to less cautiousness committers. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. From our results, we would like to make a humbly suggestion to the OSS's committers to be aware of their importance to the projects and be cautious before doing their jobs. © 2011 IEEE.

DOI

Predicting re-opened bugs: A case study on the Eclipse project

Emad Shihab, Akinori Ihara, Yasutaka Kamei, Walid M. Ibrahim, Masao Ohira, Bram Adams, Ahmed E. Hassan, Ken-Ichi Matsumoto

Proceedings - Working Conference on Reverse Engineering, WCRE ( IEEE Computer Society )    249 - 258   2010  [Refereed]

　View Summary

Bug fixing accounts for a large amount of the software maintenance resources. Generally, bugs are reported, fixed, verified and closed. However, in some cases bugs have to be re-opened. Re-opened bugs increase maintenance costs, degrade the overall user-perceived quality of the software and lead to unnecessary rework by busy practitioners. In this paper, we study and predict re-opened bugs through a case study on the Eclipse project. We structure our study along 4 dimensions: 1) the work habits dimension (e.g., the weekday on which the bug was initially closed on), 2) the bug report dimension (e.g., the component in which the bug was found) 3) the bug fix dimension (e.g., the amount of time it took to perform the initial fix) and 4) the team dimension (e.g., the experience of the bug fixer). Our case study on the Eclipse Platform 3.0 project shows that the comment and description text, the time it took to fix the bug, and the component the bug was found in are the most important factors in determining whether a bug will be re-opened. Based on these dimensions we create decision trees that predict whether a bug will be re-opened after its closure. Using a combination of our dimensions, we can build explainable prediction models that can achieve 62.9% precision and 84.5% recall when predicting whether a bug will be re-opened. © 2010 IEEE.

DOI

A Time-Lag Analysis Toward Improving the Efficiency of Communications among OSS Developers

Masao Ohira, Kiwako Koyama, Akinori Ihara, Shinsuke Matsumoto, Yasutaka Kamei, Ken-ichi Matsumoto

In Proceedings of The 3rd International Workshop on Knowledge Collaboration in Software Development (KCSD2009)     49 - 62   2009.11  [Refereed]

An Analysis Method for Improving a Bug Modification Process in Open Source Software Development

Akinori Ihara, Masao Ohira, Ken-ichi Matsumoto

IWPSE-EVOL 09: ERCIM WORKSHOP ON SOFTWARE EVOLUTION (EVOL) AND INTERNATIONAL WORKSHOP ON PRINCIPLES OF SOFTWARE EVOLUTION (IWPSE) ( ASSOC COMPUTING MACHINERY )    135 - 143   2009  [Refereed]

　View Summary

As open source software products have evolved over time to satisfy a variety of demands from increasing users, they have become large and complex in general. Open source developers often face with challenges in fixing a considerable amount of bugs which are reported into a bug tracking system on a daily basis. As a result, he mean time to resolve bugs has been protracted in these days. In order to reduce the mean time to resolve bugs, managers/leaders of open source projects need to identify and understand the bottleneck of a bug modification process in their own projects. In this paper, we propose an analysis method which represents a bug modification process using a bug tracking system as a state transition diagram and then calculates the amount of time required to transit between states. We have conducted a case study using Firefox and Apache project data to confirm the usefulness of the analysis method. From the results of the case study, we have found that the method helped to reveal that both of the projects took a lot of time to verify results of bug modifications by developers.

DOI

A Time-Lag Analysis for Improving Communication among OSS Developers.

Masao Ohira, Kiwako Koyama, Akinori Ihara, Shinsuke Matsumoto, Yasutaka Kamei, Ken-ichi Matsumoto

New Frontiers in Artificial Intelligence, JSAI-isAI 2009 Workshops, LENLS, JURISIN, KCSD, LLLL, Tokyo, Japan, November 19-20, 2009, Revised Selected Papers ( Springer )    135 - 146   2009  [Refereed]

DOI