var bibbase_data = {"data":"\"Loading..\"\n\n
\n\n \n\n \n\n \n \n\n \n\n \n \n\n \n\n \n
\n generated by\n \n \"bibbase.org\"\n\n \n
\n \n\n
\n\n \n\n\n
\n\n Excellent! Next you can\n create a new website with this list, or\n embed it in an existing web page by copying & pasting\n any of the following snippets.\n\n
\n JavaScript\n (easiest)\n
\n \n <script src=\"https://bibbase.org/service/mendeley/b3dfde71-3d8d-3b4f-b54d-dcc8724cac78/group/3650ff00-822e-3f59-b76b-d65b3771120a?jsonp=1&jsonp=1\"></script>\n \n
\n\n PHP\n
\n \n <?php\n $contents = file_get_contents(\"https://bibbase.org/service/mendeley/b3dfde71-3d8d-3b4f-b54d-dcc8724cac78/group/3650ff00-822e-3f59-b76b-d65b3771120a?jsonp=1\");\n print_r($contents);\n ?>\n \n
\n\n iFrame\n (not recommended)\n
\n \n <iframe src=\"https://bibbase.org/service/mendeley/b3dfde71-3d8d-3b4f-b54d-dcc8724cac78/group/3650ff00-822e-3f59-b76b-d65b3771120a?jsonp=1\"></iframe>\n \n
\n\n

\n For more details see the documention.\n

\n
\n
\n\n
\n\n This is a preview! To use this list on your own web site\n or create a new web site from it,\n create a free account. The file will be added\n and you will be able to edit it in the File Manager.\n We will show you instructions once you've created your account.\n
\n\n
\n\n

To the site owner:

\n\n

Action required! Mendeley is changing its\n API. In order to keep using Mendeley with BibBase past April\n 14th, you need to:\n

    \n
  1. renew the authorization for BibBase on Mendeley, and
  2. \n
  3. update the BibBase URL\n in your page the same way you did when you initially set up\n this page.\n
  4. \n
\n

\n\n

\n \n \n Fix it now\n

\n
\n\n
\n\n\n
\n \n \n
\n
\n  \n 2022\n \n \n (8)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n SôjiTantei: Function-Call Reachability Detection of Vulnerable Code for npm Packages.\n \n \n \n\n\n \n Bodin Chinthanet; Raula Gaikovina Kula; Rodrigo Eliza Zapata; Takashi Ishio; Kenichi Matsumoto; and Akinori Ihara\n\n\n \n\n\n\n IEICE Transactions on Information and Systems, E105D(1). 2022.\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 = {SôjiTantei: Function-Call Reachability Detection of Vulnerable Code for npm Packages},\n type = {article},\n year = {2022},\n keywords = {JavaScript,Reachability detection,Vulnerable code},\n volume = {E105D},\n id = {c3d6623e-7bf8-38e1-b9d3-4b0a4a57bfa0},\n created = {2022-08-02T01:00:41.600Z},\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:25:15.846Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {It has become common practice for software projects to adopt third-party dependencies. Developers are encouraged to update any outdated dependency to remain safe from potential threats of vulnerabilities. In this study, we present an approach to aid developers show whether or not a vulnerable code is reachable for JavaScript projects. Our prototype, SôjiTantei, is evaluated in two ways (i) the accuracy when compared to a manual approach and (ii) a larger-scale analysis of 780 clients from 78 security vulnerability cases. The first evaluation shows that SôjiTantei has a high accuracy of 83.3%, with a speed of less than a second analysis per client. The second evaluation reveals that 68 out of the studied 78 vulnerabilities reported having at least one clean client. The study proves that automation is promising with the potential for further improvement.},\n bibtype = {article},\n author = {Bodin Chinthanet, undefined and Raula Gaikovina Kula, undefined and Rodrigo Eliza Zapata, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined and Akinori Ihara, undefined},\n doi = {10.1587/transinf.2021MPL0001},\n journal = {IEICE Transactions on Information and Systems},\n number = {1}\n}
\n
\n\n\n
\n It has become common practice for software projects to adopt third-party dependencies. Developers are encouraged to update any outdated dependency to remain safe from potential threats of vulnerabilities. In this study, we present an approach to aid developers show whether or not a vulnerable code is reachable for JavaScript projects. Our prototype, SôjiTantei, is evaluated in two ways (i) the accuracy when compared to a manual approach and (ii) a larger-scale analysis of 780 clients from 78 security vulnerability cases. The first evaluation shows that SôjiTantei has a high accuracy of 83.3%, with a speed of less than a second analysis per client. The second evaluation reveals that 68 out of the studied 78 vulnerabilities reported having at least one clean client. The study proves that automation is promising with the potential for further improvement.\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 情報処理学会論文誌. 4 2022.\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 = {2022},\n month = {4},\n day = {15},\n id = {2dce557a-93f3-34ad-a9dc-4fa3c10be69f},\n created = {2022-08-02T02:30:02.559Z},\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:16.148Z},\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 マイクロベンチマークにおける類似プログラムの紐付け.\n \n \n \n\n\n \n 才木 一也; and 伊原 彰紀\n\n\n \n\n\n\n 第3回次世代ソフトウェアエコシステムワークショップ. 3 2022.\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 5 downloads\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 = {2022},\n month = {3},\n day = {14},\n id = {281e92bd-8e28-3b58-bf07-3864c5c9380c},\n created = {2022-08-02T02:30:03.526Z},\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-02T02:30:03.526Z},\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 = {第3回次世代ソフトウェアエコシステムワークショップ}\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 第3回次世代ソフトウェアエコシステムワークショップ. 3 2022.\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 = {2022},\n month = {3},\n day = {14},\n id = {3669c533-924f-37b1-9ad4-218020fc2145},\n created = {2022-08-02T02:30:04.489Z},\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-02T02:30:04.489Z},\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 = {第3回次世代ソフトウェアエコシステムワークショップ}\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 第84回全国大会講演論文集. 3 2022.\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 = {2022},\n month = {3},\n day = {3},\n id = {3b284009-2e9e-3563-9233-c718dada08fd},\n created = {2022-08-02T02:30:05.504Z},\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-02T02:30:05.504Z},\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 and 南 雄太, undefined},\n journal = {第84回全国大会講演論文集}\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 第84回全国大会講演論文集. 3 2022.\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 = {2022},\n month = {3},\n day = {3},\n id = {8b00cf64-1ed0-36d0-8a50-b6eafbffd6ca},\n created = {2022-08-02T02:30:06.821Z},\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-02T02:30:06.821Z},\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 and 才木 一也, undefined},\n journal = {第84回全国大会講演論文集}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 機能導入判定に向けた GitHub における要求依頼文章の分析.\n \n \n \n\n\n \n 久保 優斗; 伊原 彰紀; 石岡 直樹; 松田 和輝; and 才木 一也\n\n\n \n\n\n\n 第84回全国大会講演論文集. 3 2022.\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 = {機能導入判定に向けた GitHub における要求依頼文章の分析},\n type = {article},\n year = {2022},\n month = {3},\n day = {3},\n id = {8e384017-8ac8-3984-8ae6-9057f1018568},\n created = {2022-08-02T02:30:07.823Z},\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-02T02:30:07.823Z},\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 and 松田 和輝, undefined and 才木 一也, undefined},\n journal = {第84回全国大会講演論文集}\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 第84回全国大会講演論文集. 3 2022.\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 11 downloads\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 = {2022},\n month = {3},\n day = {3},\n id = {993fdf26-a970-387a-b8f5-33c06ae6b86a},\n created = {2022-08-02T02:30:08.776Z},\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-02T02:30:08.776Z},\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 = {第84回全国大会講演論文集}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2021\n \n \n (18)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n 🏆[Award]🏆Lags in the release, adoption, and propagation of npm vulnerability fixes.\n \n \n \n\n\n \n Bodin Chinthanet; Raula Gaikovina Kula; Shane McIntosh; Takashi Ishio; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n Empirical Software Engineering, 26(3). 2021.\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 = {🏆[Award]🏆Lags in the release, adoption, and propagation of npm vulnerability fixes},\n type = {article},\n year = {2021},\n keywords = {JavaScript,Node.js,Software library vulnerabilities,npm},\n volume = {26},\n id = {e602c715-f7f9-3462-b72e-aff045d65209},\n created = {2022-08-02T01:00:42.457Z},\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:52:38.379Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Security vulnerability in third-party dependencies is a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem, e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem.},\n bibtype = {article},\n author = {Bodin Chinthanet, undefined and Raula Gaikovina Kula, undefined and Shane McIntosh, undefined and Takashi Ishio, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/s10664-021-09951-x},\n journal = {Empirical Software Engineering},\n number = {3}\n}
\n
\n\n\n
\n Security vulnerability in third-party dependencies is a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem, e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Early Identification of Active Developers Based on their Past Contributions in OSS Projects.\n \n \n \n\n\n \n Tomoki Koguchi; and Akinori Ihara\n\n\n \n\n\n\n In Proceedings - 22nd IEEE/ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, SNPD 2021-Fall, 2021. \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 = {Early Identification of Active Developers Based on their Past Contributions in OSS Projects},\n type = {inproceedings},\n year = {2021},\n keywords = {Human factor,Machine learning,Open source software},\n id = {b795455c-87c1-3d6a-89be-f65958ba0957},\n created = {2022-08-02T01:01:06.906Z},\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:27:39.675Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Open Source Software (OSS) developers are free to contribute and free to leave a project, if the project is (not) suitable for them. On the one hand, OSS projects need to manage the human resource to continuously maintain OSS in the future. Some existing studies proposed an approach that estimates how long developers contribute to OSS projects. Using developers' contributions during the first few months in the target project, the proposed model identified long-term contributors or core developers. However, the approach frequently miss to find capable developers because many developers leave the project soon after participating. To avoid the loss of capable developers, this study build a prediction model to identify future active developers based on their past contributions to any OSS projects. Using dataset from four large-scale OSS projects as a case study, we evaluated our proposed model to identify future active developers based on their past contributions to any OSS projects before participating in a future target project. Our proposed approach contributes to manage human resource in OSS development process.},\n bibtype = {inproceedings},\n author = {Tomoki Koguchi, undefined and Akinori Ihara, undefined},\n doi = {10.1109/SNPD51163.2021.9704917},\n booktitle = {Proceedings - 22nd IEEE/ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, SNPD 2021-Fall}\n}
\n
\n\n\n
\n Open Source Software (OSS) developers are free to contribute and free to leave a project, if the project is (not) suitable for them. On the one hand, OSS projects need to manage the human resource to continuously maintain OSS in the future. Some existing studies proposed an approach that estimates how long developers contribute to OSS projects. Using developers' contributions during the first few months in the target project, the proposed model identified long-term contributors or core developers. However, the approach frequently miss to find capable developers because many developers leave the project soon after participating. To avoid the loss of capable developers, this study build a prediction model to identify future active developers based on their past contributions to any OSS projects. Using dataset from four large-scale OSS projects as a case study, we evaluated our proposed model to identify future active developers based on their past contributions to any OSS projects before participating in a future target project. Our proposed approach contributes to manage human resource in OSS development process.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Linkage of Similar Code Snippets Assessed in the Micro Benchmark Service jsPerf.\n \n \n \n\n\n \n Kazuya Saiki; and Akinori Ihara\n\n\n \n\n\n\n In Proceedings - IEEE 21st International Working Conference on Source Code Analysis and Manipulation, SCAM 2021, 2021. \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 = {Linkage of Similar Code Snippets Assessed in the Micro Benchmark Service jsPerf},\n type = {inproceedings},\n year = {2021},\n keywords = {micro benchmark,program analysis,software quality,source code classification},\n id = {aab90abb-171d-352e-a3e9-bc7aff2842dc},\n created = {2022-08-02T01:01:16.604Z},\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:45:08.542Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {A benchmark is an action to assess performance (e.g., program execution time) by developers preparing and running several test cases over a long period. To reasonably assess the performance of method-level code snippets, developers could use a micro benchmark. Some micro benchmarks for JavaScript provide online web services (e.g., jsPerf and MeasureThat.net). Developers easily search code snippets with better performance in the micro benchmark service. Then, the developers will find many similar code snippets for different functions in the service because the micro benchmark service has a collection of versatile method-level code snippets. To find replaceable code snippets with better performance, we tackle to distinguish similar code snippets for different functions with more fine-grained size than method-level in micro benchmark services.This study proposes an approach to collect diverse code snippets using the similar function. The approach measures the similarity using Code2Vec between some code snippets assessed in the micro benchmark service, and find an appropriate threshold to associate with the code snippets using the similar function. Using the micro benchmark service jsPerf dataset that the authors collected, this study evaluates the usefulness of our approach. Specifically, we collect code snippets related to the most frequent topics "innerHTML vs removeChild"and "for vs forEach"assessed in jsPerf. Consequently, we find our approach achieves higher precision (98% and 92%) to identify diverse code snippets using the similar function.},\n bibtype = {inproceedings},\n author = {Kazuya Saiki, undefined and Akinori Ihara, undefined},\n doi = {10.1109/SCAM52516.2021.00038},\n booktitle = {Proceedings - IEEE 21st International Working Conference on Source Code Analysis and Manipulation, SCAM 2021}\n}
\n
\n\n\n
\n A benchmark is an action to assess performance (e.g., program execution time) by developers preparing and running several test cases over a long period. To reasonably assess the performance of method-level code snippets, developers could use a micro benchmark. Some micro benchmarks for JavaScript provide online web services (e.g., jsPerf and MeasureThat.net). Developers easily search code snippets with better performance in the micro benchmark service. Then, the developers will find many similar code snippets for different functions in the service because the micro benchmark service has a collection of versatile method-level code snippets. To find replaceable code snippets with better performance, we tackle to distinguish similar code snippets for different functions with more fine-grained size than method-level in micro benchmark services.This study proposes an approach to collect diverse code snippets using the similar function. The approach measures the similarity using Code2Vec between some code snippets assessed in the micro benchmark service, and find an appropriate threshold to associate with the code snippets using the similar function. Using the micro benchmark service jsPerf dataset that the authors collected, this study evaluates the usefulness of our approach. Specifically, we collect code snippets related to the most frequent topics \"innerHTML vs removeChild\"and \"for vs forEach\"assessed in jsPerf. Consequently, we find our approach achieves higher precision (98% and 92%) to identify diverse code snippets using the similar function.\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 第28回ソフトウェア工学の基礎ワークショップ. 11 2021.\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 = {2021},\n month = {11},\n day = {11},\n id = {81ac80dc-a10e-35e1-86b5-27b3786119a8},\n created = {2022-08-02T02:30:09.700Z},\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-02T02:30:09.700Z},\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 and 橋谷 直樹, undefined},\n journal = {第28回ソフトウェア工学の基礎ワークショップ}\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 第28回ソフトウェア工学の基礎ワークショップ. 11 2021.\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 = {2021},\n month = {11},\n day = {11},\n id = {e9fb13de-d74d-3d93-b85a-004b0cec7806},\n created = {2022-08-02T02:30:10.654Z},\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-02T02:30:10.654Z},\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 = {第28回ソフトウェア工学の基礎ワークショップ}\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 第28回ソフトウェア工学の基礎ワークショップ. 11 2021.\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 = {2021},\n month = {11},\n day = {11},\n id = {e965108b-92ed-3c50-9b13-84cc5947a447},\n created = {2022-08-02T02:30:11.649Z},\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-02T02:30:11.649Z},\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 = {第28回ソフトウェア工学の基礎ワークショップ}\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 2021年度情報処理学会関西支部支部大会予稿集. 9 2021.\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 = {2021},\n month = {9},\n day = {19},\n id = {f577b337-e947-37e7-aa5d-043747f1738a},\n created = {2022-08-02T02:30:12.661Z},\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-02T02:30:12.661Z},\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 and 橋谷 直樹, undefined},\n journal = {2021年度情報処理学会関西支部支部大会予稿集}\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 2021年度情報処理学会関西支部支部大会予稿集. 9 2021.\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 8 downloads\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 = {2021},\n month = {9},\n day = {19},\n id = {77ba1eb4-c0d0-39cd-96ea-2e5291d3026b},\n created = {2022-08-02T02:30:13.692Z},\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-02T02:30:13.692Z},\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 = {2021年度情報処理学会関西支部支部大会予稿集}\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 2021.\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 = {2021},\n month = {9},\n day = {6},\n id = {b4f8d1b7-b3ff-344b-9676-6d41bb8f3ae4},\n created = {2022-08-02T02:30:14.735Z},\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:58:19.397Z},\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 組込みソフトウェア製品開発のプロジェクト管理に対する遅延相関分析の適用に向けて.\n \n \n \n\n\n \n 市井 誠; 堀口 日向; 柏 祐太郎; 川上 真澄; 伊原 彰紀; and 大平 雅雄\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2021.\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 = {2021},\n month = {9},\n day = {6},\n id = {b2e142d8-ae8b-3e61-ade9-ca5f9389cde8},\n created = {2022-08-02T02:30:15.811Z},\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-02T02:30:15.811Z},\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 and 川上 真澄, undefined and 伊原 彰紀, undefined and 大平 雅雄, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\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 2021.\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 = {2021},\n month = {9},\n day = {6},\n id = {480d6239-ee86-3c3a-adbe-2db22f94f235},\n created = {2022-08-02T02:30:16.800Z},\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:11.720Z},\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 データサイエンスのはじめの一歩.\n \n \n \n\n\n \n 伊原 彰紀\n\n\n \n\n\n\n 有田ロータリークラブ 例会. 4 2021.\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 4 downloads\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 = {2021},\n month = {4},\n day = {8},\n id = {78eb37b3-cc5d-331c-aaf1-73bc9eb4fb63},\n created = {2022-08-02T02:30:17.795Z},\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-02T02:30:17.795Z},\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},\n journal = {有田ロータリークラブ 例会}\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 情報処理学会第83回全国大会. 3 2021.\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 = {2021},\n month = {3},\n day = {20},\n id = {77f8659a-74d0-3a05-8354-159c09f45a1a},\n created = {2022-08-02T02:30:18.766Z},\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-02T02:30:18.766Z},\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 and 橋谷 直樹, undefined},\n journal = {情報処理学会第83回全国大会}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n READMEにおける見出しの同定処理に向けた説明文分析.\n \n \n \n\n\n \n 石岡 直樹; 伊原 彰紀; and 南 雄太\n\n\n \n\n\n\n 情報処理学会第83回全国大会. 3 2021.\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 = {READMEにおける見出しの同定処理に向けた説明文分析},\n type = {article},\n year = {2021},\n month = {3},\n day = {20},\n id = {247d12f7-1740-3ed6-ba62-1bfacdb9153b},\n created = {2022-08-02T02:30:19.728Z},\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-02T02:30:19.728Z},\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 = {情報処理学会第83回全国大会}\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 研究報告ソフトウェア工学(SE). 3 2021.\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 = {2021},\n month = {3},\n day = {4},\n id = {6b6b670f-0604-312e-9b8f-21ec8c1ad79c},\n created = {2022-08-02T02:30:20.692Z},\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-02T02:30:20.692Z},\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 = {研究報告ソフトウェア工学(SE)}\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 In 研究報告ソフトウェア工学(SE), 3 2021. \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 8 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@inproceedings{\n title = {マイクロベンチマークサービスにおけるプログラム断片の分析},\n type = {inproceedings},\n year = {2021},\n month = {3},\n day = {4},\n id = {58ff5255-4ec2-3641-a85f-c0fa6823ed6d},\n created = {2022-08-02T02:30:21.785Z},\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-02T02:53:15.105Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {inproceedings},\n author = {才木 一也, undefined and 伊原 彰紀, undefined},\n booktitle = {研究報告ソフトウェア工学(SE)}\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 伊原 彰紀\n\n\n \n\n\n\n 3 2021.\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
@misc{\n title = {🏆[Award]🏆情報処理学会ソフトウェア工学研究会 功績賞 受賞},\n type = {misc},\n year = {2021},\n month = {3},\n day = {4},\n id = {e65c5b08-7345-3ad7-ad6f-ff3ff86843fa},\n created = {2022-08-09T01:34:44.435Z},\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:02:20.208Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {伊原 彰紀, undefined}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Code Reviews with Divergent Review Scores: An Empirical Study of the OpenStack and Qt Communities.\n \n \n \n\n\n \n Toshiki Hirao; Shane McIntosh; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n IEEE Transactions on Software Engineering, 48(1). 5 2021.\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 = {Code Reviews with Divergent Review Scores: An Empirical Study of the OpenStack and Qt Communities},\n type = {article},\n year = {2021},\n keywords = {Modern code review,divergent discussion,empirical study},\n volume = {48},\n month = {5},\n day = {25},\n id = {00fe8e32-b8fe-3351-979c-21ce7cda3c86},\n created = {2022-08-19T02:22:37.928Z},\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:16:29.705Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Code review is a broadly adopted software quality practice where developers critique each others' patches. In addition to providing constructive feedback, reviewers may provide a score to indicate whether the patch should be integrated. Since reviewer opinions may differ, patches can receive both positive and negative scores. If reviews with divergent scores are not carefully resolved, they may contribute to a tense reviewing culture and may slow down integration. In this article, we study patches with divergent review scores in the OpenStack and Qt communities. Quantitative analysis indicates that patches with divergent review scores: (1) account for 15-37 percent of patches that receive multiple review scores; (2) are integrated more often than they are abandoned; and (3) receive negative scores after positive ones in 70 percent of cases. Furthermore, a qualitative analysis indicates that patches with strongly divergent scores that: (4) are abandoned more often suffer from external issues (e.g., integration planning, content duplication) than patches with weakly divergent scores and patches without divergent scores; and (5) are integrated often address reviewer concerns indirectly (i.e., without changing patches). Our results suggest that review tooling should integrate with release schedules and detect concurrent development of similar patches to optimize review discussions with divergent scores. Moreover, patch authors should note that even the most divisive patches are often integrated through discussion, integration timing, and careful revision.},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Shane McIntosh, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/TSE.2020.2977907},\n journal = {IEEE Transactions on Software Engineering},\n number = {1}\n}
\n
\n\n\n
\n Code review is a broadly adopted software quality practice where developers critique each others' patches. In addition to providing constructive feedback, reviewers may provide a score to indicate whether the patch should be integrated. Since reviewer opinions may differ, patches can receive both positive and negative scores. If reviews with divergent scores are not carefully resolved, they may contribute to a tense reviewing culture and may slow down integration. In this article, we study patches with divergent review scores in the OpenStack and Qt communities. Quantitative analysis indicates that patches with divergent review scores: (1) account for 15-37 percent of patches that receive multiple review scores; (2) are integrated more often than they are abandoned; and (3) receive negative scores after positive ones in 70 percent of cases. Furthermore, a qualitative analysis indicates that patches with strongly divergent scores that: (4) are abandoned more often suffer from external issues (e.g., integration planning, content duplication) than patches with weakly divergent scores and patches without divergent scores; and (5) are integrated often address reviewer concerns indirectly (i.e., without changing patches). Our results suggest that review tooling should integrate with release schedules and detect concurrent development of similar patches to optimize review discussions with divergent scores. Moreover, patch authors should note that even the most divisive patches are often integrated through discussion, integration timing, and careful revision.\n
\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2020\n \n \n (8)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Analysis of prevalent code improvements through code review.\n \n \n \n\n\n \n Yuki Ueda; Takashi Ishio; Kenichi Matsumoto; and Akinori Ihara\n\n\n \n\n\n\n Computer Software, 37(2). 2020.\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
@article{\n title = {Analysis of prevalent code improvements through code review},\n type = {article},\n year = {2020},\n volume = {37},\n id = {b32d6bf3-74ff-3fb1-b941-6e12dbbc0cd5},\n created = {2022-08-02T01:01:26.611Z},\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:12:50.025Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Open-source software evolves into high-performance and high-quality software by accepting submissions of source code changes from many patch authors. However, source code changes that are submitted to a project does not always obey projects’ coding conventions defined. Hence, reviewers waste a large amount of time to verify source code and suggest source code improvements for patch authors. The time to improve source code can be reduced if patch authors solve these issues by themselves before patch submissions. To investigate an understandable checklist for developers in addition to coding conventions, this study analyzes source code improvement contents that are frequently solved on code review. From four Python project datasets, we found 56.0% code changes do not have an impact on behavior. We also found that only 13.4% of code improvements could be verified by using static analysis tools. As a contribution, we revealed the source code changes in code review and the improvement contents that can detect before submitting the patch by using the static analysis tools.},\n bibtype = {article},\n author = {Yuki Ueda, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined and Akinori Ihara, undefined},\n doi = {10.11309/jssst.37.2_76},\n journal = {Computer Software},\n number = {2}\n}
\n
\n\n\n
\n Open-source software evolves into high-performance and high-quality software by accepting submissions of source code changes from many patch authors. However, source code changes that are submitted to a project does not always obey projects’ coding conventions defined. Hence, reviewers waste a large amount of time to verify source code and suggest source code improvements for patch authors. The time to improve source code can be reduced if patch authors solve these issues by themselves before patch submissions. To investigate an understandable checklist for developers in addition to coding conventions, this study analyzes source code improvement contents that are frequently solved on code review. From four Python project datasets, we found 56.0% code changes do not have an impact on behavior. We also found that only 13.4% of code improvements could be verified by using static analysis tools. As a contribution, we revealed the source code changes in code review and the improvement contents that can detect before submitting the patch by using the static analysis tools.\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 第27回ソフトウェア工学の基礎ワークショップ. 11 2020.\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 = {2020},\n month = {11},\n day = {20},\n id = {ba38e6b5-0977-32bc-9947-9726aea8acc8},\n created = {2022-08-02T02:59:21.477Z},\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-02T02:59:21.477Z},\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 = {第27回ソフトウェア工学の基礎ワークショップ}\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 ソフトウェアエンジニアリングシンポジウム. 9 2020.\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 = {2020},\n month = {9},\n day = {20},\n id = {88f15770-9676-31a6-9736-28f977187306},\n created = {2022-08-02T02:59:22.351Z},\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-02T02:59:22.351Z},\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 社会的相互作用に着目したGitHubへのスター付与数の見積もり手法.\n \n \n \n\n\n \n 橋本 大輝; 伊原 彰紀; and 小口 知希\n\n\n \n\n\n\n 情報処理学会関西支部支部大会. 9 2020.\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 = {社会的相互作用に着目したGitHubへのスター付与数の見積もり手法},\n type = {article},\n year = {2020},\n month = {9},\n day = {20},\n id = {b17888bd-b586-3675-a338-4ba9cde8c514},\n created = {2022-08-02T02:59:23.261Z},\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-02T03:03:03.682Z},\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 = {情報処理学会関西支部支部大会}\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\n\n\n 技術情報誌TELECOM FRONTIER. 8 2020.\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 8 downloads\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 = {2020},\n month = {8},\n day = {1},\n id = {1e8da36c-c7c6-3c2e-9b57-59e3a556baf7},\n created = {2022-08-02T02:59:24.177Z},\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-02T02:59:24.177Z},\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},\n journal = {技術情報誌TELECOM FRONTIER}\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 電子情報通信学会技術研究報告. 3 2020.\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 = {2020},\n month = {3},\n day = {4},\n id = {504a1e7a-2a96-3840-bc75-033b628b5b40},\n created = {2022-08-02T06:08:54.407Z},\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:54.407Z},\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 = {電子情報通信学会技術研究報告}\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 コンピュータソフトウェア. 3 2020.\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 2 downloads\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 = {2020},\n month = {3},\n day = {1},\n id = {134885a4-5872-33a4-ba6c-e925172cf325},\n created = {2022-08-02T06:08:55.364Z},\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:55.364Z},\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 and 松本 健一, undefined},\n journal = {コンピュータソフトウェア}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソフトウェア品質知識体系ガイド(第3版) – SQuBOK Guide V3 -.\n \n \n \n\n\n \n 飯泉 紀子 監修、鷲崎 弘宜 監修、誉田 直美 監修、SQuBOK策定部会 編(第5章の一部を伊原が執筆)\n\n\n \n\n\n\n 11 2020.\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
@misc{\n title = {ソフトウェア品質知識体系ガイド(第3版) – SQuBOK Guide V3 -},\n type = {misc},\n year = {2020},\n month = {11},\n publisher = {オーム社},\n day = {21},\n id = {4583b829-3fb3-3422-a22d-2b7c945baaf1},\n created = {2022-08-09T01:35:15.840Z},\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-09T01:35:15.840Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {飯泉 紀子 監修、鷲崎 弘宜 監修、誉田 直美 監修、SQuBOK策定部会 編(第5章の一部を伊原が執筆), undefined}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2019\n \n \n (19)\n \n \n
\n
\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 Understanding developer commenting in code reviews.\n \n \n \n\n\n \n Toshiki Hirao; Raula Gaikovina Kula; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n IEICE Transactions on Information and Systems, E102D(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\n\n\n
\n
@article{\n title = {Understanding developer commenting in code reviews},\n type = {article},\n year = {2019},\n keywords = {Empirical study,Machine learning,Mining software repositories,Modern code review,Review comments},\n volume = {E102D},\n id = {65c887d9-fec1-3ed5-a5e7-ce8f12a74658},\n created = {2022-08-02T01:00:47.091Z},\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:32:12.000Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Modern code review is a well-known practice to assess the quality of software where developers discuss the quality in a web-based review tool. However, this lightweight approach may risk an inefficient review participation, especially when comments becomes either excessive (i.e., too many) or underwhelming (i.e., too few). In this study, we investigate the phenomena of reviewer commenting. Through a large-scale empirical analysis of over 1.1 million reviews from five OSS systems, we conduct an exploratory study to investigate the frequency, size, and evolution of reviewer commenting. Moreover, we also conduct a modeling study to understand the most important features that potentially drive reviewer comments. Our results find that (i) the number of comments and the number of words in the comments tend to vary among reviews and across studied systems; (ii) reviewers change their behaviours in commenting over time; and (iii) human experience and patch property aspects impact the number of comments and the number of words in the comments.},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Raula Gaikovina Kula, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1587/transinf.2019MPP0005},\n journal = {IEICE Transactions on Information and Systems},\n number = {12}\n}
\n
\n\n\n
\n Modern code review is a well-known practice to assess the quality of software where developers discuss the quality in a web-based review tool. However, this lightweight approach may risk an inefficient review participation, especially when comments becomes either excessive (i.e., too many) or underwhelming (i.e., too few). In this study, we investigate the phenomena of reviewer commenting. Through a large-scale empirical analysis of over 1.1 million reviews from five OSS systems, we conduct an exploratory study to investigate the frequency, size, and evolution of reviewer commenting. Moreover, we also conduct a modeling study to understand the most important features that potentially drive reviewer comments. Our results find that (i) the number of comments and the number of words in the comments tend to vary among reviews and across studied systems; (ii) reviewers change their behaviours in commenting over time; and (iii) human experience and patch property aspects impact the number of comments and the number of words in the comments.\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 Understanding Usages, Updates, and Risks of Static Analysis Tool in Open Source Software Projects.\n \n \n \n\n\n \n Yuta Minami; Akinori Ihara; and Haruki Fukumoto\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 = {Understanding Usages, Updates, and Risks of Static Analysis Tool in Open Source Software Projects},\n type = {article},\n year = {2019},\n month = {12},\n day = {13},\n id = {30dafd21-e1bd-3e7b-b723-cd67673c08dd},\n created = {2022-08-02T06:08:56.902Z},\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:56.902Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Yuta Minami, undefined and Akinori Ihara, undefined and Haruki Fukumoto, 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 An Analysis of Patch Acceptance Using Test Case Generation Tool.\n \n \n \n\n\n \n Haruki Fukumoto; Akinori Ihara; Takashi Ishio; and Yuki Ueda\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 Patch Acceptance Using Test Case Generation Tool},\n type = {article},\n year = {2019},\n month = {12},\n day = {13},\n id = {084cd4bf-56d8-30f8-9b03-b5da0995a6cf},\n created = {2022-08-02T06:08:57.920Z},\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:57.920Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Haruki Fukumoto, undefined and Akinori Ihara, undefined and Takashi Ishio, undefined and Yuki Ueda, 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 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 Identification of Future Active Contributors based on Activities in Outside OSS Community.\n \n \n \n\n\n \n Tomoki Koguchi; Akinori Ihara; and Tomohiro Inagaki\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 = {Identification of Future Active Contributors based on Activities in Outside OSS Community},\n type = {article},\n year = {2019},\n month = {12},\n day = {13},\n id = {292c12ae-aae3-3a67-a587-3fc143363312},\n created = {2022-08-02T06:08:59.807Z},\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:59.807Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Tomoki Koguchi, undefined and Akinori Ihara, undefined and Tomohiro Inagaki, 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 小口 知希; 伊原 彰紀; 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
\n
\n\n
\n
\n  \n 2018\n \n \n (21)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Extraction of library update history using source code reuse detection.\n \n \n \n\n\n \n Kanyakorn Jewmaidang; Takashi Ishio; Akinori Ihara; Kenichi Matsumoto; and Pattara Leelaprute\n\n\n \n\n\n\n IEICE Transactions on Information and Systems, E101D(3). 2018.\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 = {Extraction of library update history using source code reuse detection},\n type = {article},\n year = {2018},\n keywords = {Repository mining,Software reuse,Source code similarity,Visualization},\n volume = {E101D},\n id = {a3c8a3ac-caa7-35f7-b6eb-4d24788f5b00},\n created = {2022-08-02T01:00:57.793Z},\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:30:28.215Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {article},\n author = {Kanyakorn Jewmaidang, undefined and Takashi Ishio, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined and Pattara Leelaprute, undefined},\n doi = {10.1587/transinf.2017EDL8205},\n journal = {IEICE Transactions on Information and Systems},\n number = {3}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Maintaining third-party libraries through domain-specific category recommendations.\n \n \n \n\n\n \n Daiki Katsuragawa; Akinori Ihara; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - International Conference on Software Engineering, 2018. \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
@inproceedings{\n title = {Maintaining third-party libraries through domain-specific category recommendations},\n type = {inproceedings},\n year = {2018},\n id = {54dcfeeb-f47b-3db4-a5db-4f931086e83f},\n created = {2022-08-02T01:01:05.114Z},\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:47:08.241Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Proper maintenance of third-party libraries contributes toward sustaining a healthy project, mitigating the risk it becoming outdated and obsolete. In this paper, we propose domain-specific categories (i.e., grouping of libraries that perform similar functionality) in library recommendations that aids in library maintenance. Our empirical study covers 2,511 GitHub projects and 150 domain-specific categories of Java libraries. Our results show that a system uses up to six different categories in their dependencies. Furthermore, recommending domain-specific categories is practical (i.e., with an accuracy between 66% to 81% for multiple categories) and its suggestion of libraries within that domain is comparable to existing techniques.},\n bibtype = {inproceedings},\n author = {Daiki Katsuragawa, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/3194124.3194129},\n booktitle = {Proceedings - International Conference on Software Engineering}\n}
\n
\n\n\n
\n Proper maintenance of third-party libraries contributes toward sustaining a healthy project, mitigating the risk it becoming outdated and obsolete. In this paper, we propose domain-specific categories (i.e., grouping of libraries that perform similar functionality) in library recommendations that aids in library maintenance. Our empirical study covers 2,511 GitHub projects and 150 domain-specific categories of Java libraries. Our results show that a system uses up to six different categories in their dependencies. Furthermore, recommending domain-specific categories is practical (i.e., with an accuracy between 66% to 81% for multiple categories) and its suggestion of libraries within that domain is comparable to existing techniques.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Do review feedbacks influence to a contributor's time spent on oss projects?.\n \n \n \n\n\n \n Takuto Norikane; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 2018 IEEE/ACIS 3rd International Conference on Big Data, Cloud Computing, Data Science and Engineering, BCD 2018, 2018. \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 = {Do review feedbacks influence to a contributor's time spent on oss projects?},\n type = {inproceedings},\n year = {2018},\n keywords = {Code-review-feedback,Long-term-contributors,Open-source-software-development},\n id = {f033fe05-9996-30f6-992f-70bfdf3a7a8c},\n created = {2022-08-02T01:01:09.611Z},\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:20:02.590Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Takuto Norikane, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/BCD2018.2018.00028},\n booktitle = {Proceedings - 2018 IEEE/ACIS 3rd International Conference on Big Data, Cloud Computing, Data Science and Engineering, BCD 2018}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n An analysis of library rollbacks: A case study of Java libraries.\n \n \n \n\n\n \n Hirohiko Suwa; Akinori Ihara; Raula Gaikovina Kula; Daiki Fujibayashi; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 2017 24th Asia-Pacific Software Engineering Conference Workshops, APSECW 2017, volume 2018-Janua, 2018. \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 = {An analysis of library rollbacks: A case study of Java libraries},\n type = {inproceedings},\n year = {2018},\n keywords = {Java libraries,Migration,Rollback},\n volume = {2018-Janua},\n id = {f07a8967-e8cd-3f32-ac7c-328e8f890d66},\n created = {2022-08-02T01:01:19.951Z},\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:03:03.311Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {To take full advantage of third-party library functionality, developers of a software are encouraged to constantly migrate their library dependencies. When developers migrate a library, a library rollback may occur during a migration. The library rollback is a process of restoring the software to the previously defined library state, typically to recover because a library that could not integrate with that software based on any reasons. To ensure a quick successful migration of a new library or version, developers should avoid the time and resource costs of such rollbacks. In this paper, we investigate factors leading to a rollback during library migration. We propose an empirical method to detect rollbacks and apply it to 9,357 projects from GitHub that have been adopted by around 50 Maven libraries. The results indicate that dependencies with shorter release cycles are more likely to have a rollback.Furthermore, a project that responds more quickly to a newer library is more likely to have a rollback. We recommend that developers consider project version type, latency time and the release cycle of a library during library migration.},\n bibtype = {inproceedings},\n author = {Hirohiko Suwa, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Daiki Fujibayashi, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/APSECW.2017.25},\n booktitle = {Proceedings - 2017 24th Asia-Pacific Software Engineering Conference Workshops, APSECW 2017}\n}
\n
\n\n\n
\n To take full advantage of third-party library functionality, developers of a software are encouraged to constantly migrate their library dependencies. When developers migrate a library, a library rollback may occur during a migration. The library rollback is a process of restoring the software to the previously defined library state, typically to recover because a library that could not integrate with that software based on any reasons. To ensure a quick successful migration of a new library or version, developers should avoid the time and resource costs of such rollbacks. In this paper, we investigate factors leading to a rollback during library migration. We propose an empirical method to detect rollbacks and apply it to 9,357 projects from GitHub that have been adopted by around 50 Maven libraries. The results indicate that dependencies with shorter release cycles are more likely to have a rollback.Furthermore, a project that responds more quickly to a newer library is more likely to have a rollback. We recommend that developers consider project version type, latency time and the release cycle of a library during library migration.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n The impact of IR-based classifier configuration on the performance and the effort of method-level bug localization.\n \n \n \n\n\n \n Chakkrit Tantithamthavorn; Surafel Lemma Abebe; Ahmed E. Hassan; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n Information and Software Technology, 102. 2018.\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\n
\n
@article{\n title = {The impact of IR-based classifier configuration on the performance and the effort of method-level bug localization},\n type = {article},\n year = {2018},\n keywords = {Bug localization,Classifier configuration,Effort,Evaluation metrics,Top-k performance},\n volume = {102},\n id = {9d1ba4db-6ba2-3a2b-8534-2b23649526bb},\n created = {2022-08-02T01:01:21.751Z},\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:02:33.501Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {article},\n author = {Chakkrit Tantithamthavorn, undefined and Surafel Lemma Abebe, undefined and Ahmed E. Hassan, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1016/j.infsof.2018.06.001},\n journal = {Information and Software Technology}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n How are IF-conditional statements fixed through peer code review?.\n \n \n \n\n\n \n Yuki Ueda; Akinori Ihara; Takashi Ishio; Toshiki Hirao; and Kenichi Matsumoto\n\n\n \n\n\n\n IEICE Transactions on Information and Systems, E101D(11). 2018.\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 = {How are IF-conditional statements fixed through peer code review?},\n type = {article},\n year = {2018},\n keywords = {Code readability,CodeReview,If statement},\n volume = {E101D},\n id = {27766bf8-e74e-399b-a7ce-a3c3cf7f5375},\n created = {2022-08-02T01:01:29.293Z},\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:33:19.356Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Peer code review is key to ensuring the absence of software defects. To reduce review costs, software developers adopt code convention checking tools that automatically identify maintainability issues in source code. However, these tools do not always address the maintainability issue for a particular project. The goal of this study is to understand how code review fixes conditional statement issues, which are the most frequent changes in software development. We conduct an empirical study to understand if-statement changes through code review. Using review requests in the Qt and OpenStack projects, we analyze changes of the if-conditional statements that are (1) requested to be reviewed, and are (2) revised through code review. We find the most frequently changed symbols are "( )", ".", and "!". We also find project-specific fixing patterns for improving code readability by association rule mining. For example "!" operator is frequently replaced with a function call. These rules are useful for improving a coding convention checker tailored for the projects.},\n bibtype = {article},\n author = {Yuki Ueda, undefined and Akinori Ihara, undefined and Takashi Ishio, undefined and Toshiki Hirao, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1587/transinf.2018EDP7004},\n journal = {IEICE Transactions on Information and Systems},\n number = {11}\n}
\n
\n\n\n
\n Peer code review is key to ensuring the absence of software defects. To reduce review costs, software developers adopt code convention checking tools that automatically identify maintainability issues in source code. However, these tools do not always address the maintainability issue for a particular project. The goal of this study is to understand how code review fixes conditional statement issues, which are the most frequent changes in software development. We conduct an empirical study to understand if-statement changes through code review. Using review requests in the Qt and OpenStack projects, we analyze changes of the if-conditional statements that are (1) requested to be reviewed, and are (2) revised through code review. We find the most frequently changed symbols are \"( )\", \".\", and \"!\". We also find project-specific fixing patterns for improving code readability by association rule mining. For example \"!\" operator is frequently replaced with a function call. These rules are useful for improving a coding convention checker tailored for the projects.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n An empirical study of design discussions in code review.\n \n \n \n\n\n \n Farida El Zanaty; Toshiki Hirao; Shane McIntosh; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In International Symposium on Empirical Software Engineering and Measurement, 2018. \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 = {An empirical study of design discussions in code review},\n type = {inproceedings},\n year = {2018},\n keywords = {Code review,Mining software repositories,Software design},\n id = {197614ab-d92d-3333-9126-c059fe0b5323},\n created = {2022-08-02T01:01:31.203Z},\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:05:07.329Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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 < 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.},\n bibtype = {inproceedings},\n author = {Farida El Zanaty, undefined and Toshiki Hirao, undefined and Shane McIntosh, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/3239235.3239525},\n booktitle = {International Symposium on Empirical Software Engineering and Measurement}\n}
\n
\n\n\n
\n 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 < 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Towards smoother library migrations: a look at vulnerable dependency migrations at function level for npm javascript packages.\n \n \n \n\n\n \n Rodrigo Elizalde Zapata; Raula Gaikovina Kula; Bodin Chinthanet; Takashi Ishio; Kenichi Matsumoto; and Akinori Ihara\n\n\n \n\n\n\n In Proceedings - 2018 IEEE International Conference on Software Maintenance and Evolution, ICSME 2018, 2018. \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 = {Towards smoother library migrations: a look at vulnerable dependency migrations at function level for npm javascript packages},\n type = {inproceedings},\n year = {2018},\n keywords = {Libraries tracking,Libraries updates,Third party libraries},\n id = {49c8edc1-5912-3164-b462-d384f3cad7ee},\n created = {2022-08-02T01:01:32.108Z},\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-23T00:58:23.407Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {It has become common practice for software projects to adopt third-party libraries, allowing developers full access to functions that otherwise will take time and effort to create them-selves. Regardless of migration effort involved, developers are encouraged to maintain their library dependencies by updating any outdated dependency, so as to remain safe from potential threats such as vulnerabilities. Through a manual inspection of a total of 60 client projects from three cases of high severity vulnerabilities, we investigate whether or not clients are really safe from these threats. Surprisingly, our early results show evidence that up to 73.3% of outdated clients were actually safe from the threat. This is the first work to confirm that analysis at the library level is indeed an overestimation. This result to pave the path for future studies to empirically investigate and validate this phenomena, and is towards aiding a smoother library migration for client developers.},\n bibtype = {inproceedings},\n author = {Rodrigo Elizalde Zapata, undefined and Raula Gaikovina Kula, undefined and Bodin Chinthanet, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined and Akinori Ihara, undefined},\n doi = {10.1109/ICSME.2018.00067},\n booktitle = {Proceedings - 2018 IEEE International Conference on Software Maintenance and Evolution, ICSME 2018}\n}
\n
\n\n\n
\n It has become common practice for software projects to adopt third-party libraries, allowing developers full access to functions that otherwise will take time and effort to create them-selves. Regardless of migration effort involved, developers are encouraged to maintain their library dependencies by updating any outdated dependency, so as to remain safe from potential threats such as vulnerabilities. Through a manual inspection of a total of 60 client projects from three cases of high severity vulnerabilities, we investigate whether or not clients are really safe from these threats. Surprisingly, our early results show evidence that up to 73.3% of outdated clients were actually safe from the threat. This is the first work to confirm that analysis at the library level is indeed an overestimation. This result to pave the path for future studies to empirically investigate and validate this phenomena, and is towards aiding a smoother library migration for client developers.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Analysis of Library Usage in Various Software Packaging Ecosystems.\n \n \n \n\n\n \n Daiki Katsuragawa; Akinori Ihara; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 12 2018.\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 = {Analysis of Library Usage in Various Software Packaging Ecosystems},\n type = {article},\n year = {2018},\n month = {12},\n day = {4},\n id = {25f6b025-5997-3bdd-9f80-0fd0cd1b019e},\n created = {2022-08-02T06:09:06.604Z},\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:06.604Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Daiki Katsuragawa, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, 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 Using static and dynamic analysis to provide smoother library migrations in npm.\n \n \n \n\n\n \n Rodrigo Elizalde; Raula Kula; Bodin Chinthanet; Takashi Ishio; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 12 2018.\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 = {Using static and dynamic analysis to provide smoother library migrations in npm},\n type = {article},\n year = {2018},\n month = {12},\n day = {4},\n id = {de8566b5-66ff-3214-813f-a21df7f5f33d},\n created = {2022-08-02T06:09:07.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-02T06:09:07.594Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Rodrigo Elizalde, undefined and Raula Kula, undefined and Bodin Chinthanet, undefined and Takashi Ishio, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, 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 An analysis of technical contributions across projects for identifying future collaborator in OSS projects.\n \n \n \n\n\n \n Tomoki Koguchi; and Akinori Ihara\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 12 2018.\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 technical contributions across projects for identifying future collaborator in OSS projects},\n type = {article},\n year = {2018},\n month = {12},\n day = {4},\n id = {bd8e136a-eb42-3a87-ab61-ef0974aaf79f},\n created = {2022-08-02T06:09:08.480Z},\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:08.480Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Tomoki Koguchi, 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 How do interest modules of OSS developers move? - A case study of Junit project.\n \n \n \n\n\n \n Takuto Yoshimoto; and Akinori Ihara\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 12 2018.\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 = {How do interest modules of OSS developers move? - A case study of Junit project},\n type = {article},\n year = {2018},\n month = {12},\n day = {4},\n id = {45679940-4937-3e03-b86f-1a46068a7a89},\n created = {2022-08-02T06:09:09.362Z},\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:09.362Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Takuto Yoshimoto, 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 🏆[Award]🏆Toward identifying similar program without using Remix in Scratch.\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 2018.\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]🏆Toward identifying similar program without using Remix in Scratch},\n type = {article},\n year = {2018},\n month = {12},\n day = {4},\n id = {237bbac5-601c-3485-8bb3-b087496d99c8},\n created = {2022-08-02T06:09:10.301Z},\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:56:32.744Z},\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 \n\n\n\n 11 2018.\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 2 downloads\n \n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@misc{\n title = {ソフトウェア自動検証技術の開発},\n type = {misc},\n year = {2018},\n source = {第27回わかやまテクノ・ビジネスフェア わかやま発技術シーズ発表会},\n month = {11},\n day = {7},\n id = {6570085c-4392-39a0-89e2-8d764e400666},\n created = {2022-08-02T06:09:11.286Z},\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:11.286Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {伊原 彰紀, undefined}\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 第25回ソフトウェア工学の基礎ワークショップ. 11 2018.\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 = {2018},\n month = {11},\n day = {15},\n id = {30d460f4-802f-3f76-9e79-3740750482dc},\n created = {2022-08-02T06:09:12.247Z},\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:59:12.671Z},\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 and 松本 健一, undefined},\n journal = {第25回ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 開発状況メトリクスを用いたOSS不具合修正時間予測モデル.\n \n \n \n\n\n \n 伊原 彰紀; 若本 亮樹; and 松本 健一\n\n\n \n\n\n\n 9 2018.\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
@misc{\n title = {開発状況メトリクスを用いたOSS不具合修正時間予測モデル},\n type = {misc},\n year = {2018},\n month = {9},\n day = {5},\n id = {7852fb1a-2fe9-3fe4-8caf-852f839eb57c},\n created = {2022-08-02T06:09:13.189Z},\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-30T02:34:20.765Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {伊原 彰紀, undefined and 若本 亮樹, undefined and 松本 健一, undefined}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 開発状況メトリクスを用いたOSS不具合修正時間予測モデル.\n \n \n \n\n\n \n 伊原 彰紀; 若本 亮樹; and 松本 健一\n\n\n \n\n\n\n 情報処理学会論文誌. 3 2018.\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 = {開発状況メトリクスを用いたOSS不具合修正時間予測モデル},\n type = {article},\n year = {2018},\n month = {3},\n day = {15},\n id = {96395f9b-55d5-35da-8ce3-4950312948e5},\n created = {2022-08-09T01:34:56.254Z},\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-09T01:34:56.254Z},\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 = {情報処理学会論文誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソフトウェア開発における同時バージョン変更される併用ライブラリの推薦.\n \n \n \n\n\n \n Daiki Katsuragawa; Akinori Ihara; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2018.\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 = {2018},\n month = {7},\n day = {3},\n id = {3bdf8400-4ac5-3265-8369-53a6dc59f12d},\n created = {2022-08-09T01:35:25.374Z},\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-09T01:35:25.374Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Daiki Katsuragawa, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソーシャルコーディングにおけるソースコード中の If 文自動検証システムの開発.\n \n \n \n\n\n \n Yuki Ueda; Akinori Ihara; Takashi Ishio; Daiki Katsuragawa; Sumie Morita; Suhinji Kikuchi; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2018.\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 = {ソーシャルコーディングにおけるソースコード中の If 文自動検証システムの開発},\n type = {article},\n year = {2018},\n month = {7},\n day = {3},\n id = {09211ce0-fa5d-31d4-8832-998379d0b5af},\n created = {2022-08-09T01:35:29.532Z},\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-09T01:35:29.532Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Yuki Ueda, undefined and Akinori Ihara, undefined and Takashi Ishio, undefined and Daiki Katsuragawa, undefined and Sumie Morita, undefined and Suhinji Kikuchi, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSコミュニティにおける開発者の活動継続性を理解するためのPoliteness分析.\n \n \n \n\n\n \n Tomoki Miyazaki; Akinori Ihara; Masao Ohira; Yunosuke Higashi; and Yosuke Yamatani\n\n\n \n\n\n\n 情報処理学会論文誌. 2 2018.\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 = {OSSコミュニティにおける開発者の活動継続性を理解するためのPoliteness分析},\n type = {article},\n year = {2018},\n month = {2},\n id = {9f5ddcef-b474-3cd1-acb4-8bb19962dafd},\n created = {2022-08-09T01:36:57.643Z},\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-09T01:36:57.643Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Tomoki Miyazaki, undefined and Akinori Ihara, undefined and Masao Ohira, undefined and Yunosuke Higashi, undefined and Yosuke Yamatani, undefined},\n journal = {情報処理学会論文誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆IEEE Kansai Section Young Professionals Award.\n \n \n \n\n\n \n Akinori Ihara\n\n\n \n\n\n\n 2 2018.\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
@misc{\n title = {🏆[Award]🏆IEEE Kansai Section Young Professionals Award},\n type = {misc},\n year = {2018},\n source = {IEEE Kansai Section},\n month = {2},\n day = {22},\n id = {856d0cb1-194d-33f2-9650-ffd672e3d263},\n created = {2022-08-09T01:37:11.757Z},\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:51:45.228Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {Akinori Ihara, undefined}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2017\n \n \n (15)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Does the release cycle of a library project influence when it is adopted by a client project?.\n \n \n \n\n\n \n Akinori Ihara; Daiki Fujibayashi; Hirohiko Suwa; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n In SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering, 2017. \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
@inproceedings{\n title = {Does the release cycle of a library project influence when it is adopted by a client project?},\n type = {inproceedings},\n year = {2017},\n id = {6f172630-6846-3b71-b532-085f2df6a991},\n created = {2022-08-02T01:00:43.342Z},\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:23:44.926Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Akinori Ihara, undefined and Daiki Fujibayashi, undefined and Hirohiko Suwa, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/SANER.2017.7884681},\n booktitle = {SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆Understanding when to adopt a library: A case study on ASF projects.\n \n \n \n\n\n \n Akinori Ihara; Daiki Fujibayashi; Hirohiko Suwa; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n Volume 496 2017.\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
@book{\n title = {🏆[Award]🏆Understanding when to adopt a library: A case study on ASF projects},\n type = {book},\n year = {2017},\n source = {IFIP Advances in Information and Communication Technology},\n volume = {496},\n id = {6633b58d-8b82-30a6-8586-220136b8c609},\n created = {2022-08-02T01:00:49.775Z},\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:57:58.390Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {book},\n author = {Akinori Ihara, undefined and Daiki Fujibayashi, undefined and Hirohiko Suwa, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/978-3-319-57735-7_13}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Understanding key features of high-impact bug reports.\n \n \n \n\n\n \n Md. Rejaul Karim; Akinori Ihara; Xin Yang; Hajimu Iida; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 8th IEEE International Workshop on Empirical Software Engineering in Practice, IWESEP 2017, 2017. \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 = {Understanding key features of high-impact bug reports},\n type = {inproceedings},\n year = {2017},\n keywords = {Bug Report,Bug Tracking System,High-impact Bug,Open Source},\n id = {a4d48e39-b449-3744-92dc-3539a4d9b213},\n created = {2022-08-02T01:01:03.374Z},\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:33:32.259Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Md. Rejaul Karim, undefined and Akinori Ihara, undefined and Xin Yang, undefined and Hajimu Iida, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/IWESEP.2017.17},\n booktitle = {Proceedings - 8th IEEE International Workshop on Empirical Software Engineering in Practice, IWESEP 2017}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Which review feedback did long-term contributors get on OSS projects?.\n \n \n \n\n\n \n Takuto Norikane; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering, 2017. \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
@inproceedings{\n title = {Which review feedback did long-term contributors get on OSS projects?},\n type = {inproceedings},\n year = {2017},\n id = {e5a73acf-1d74-3540-a842-d08a2907d441},\n created = {2022-08-02T01:01:11.285Z},\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:13:34.662Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Takuto Norikane, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/SANER.2017.7884682},\n booktitle = {SANER 2017 - 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n How is if statement fixed through code review? A case study of QT project.\n \n \n \n\n\n \n Yuki Ueda; Akinori Ihara; Toshiki Hirao; Takashi Ishio; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 2017 IEEE 28th International Symposium on Software Reliability Engineering Workshops, ISSREW 2017, 2017. \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\n
\n
@inproceedings{\n title = {How is if statement fixed through code review? A case study of QT project},\n type = {inproceedings},\n year = {2017},\n keywords = {Code review,Conditional statement,Fix detection,If statement,Static code analysis},\n id = {f04c1b18-2804-3a68-8c1d-c431c3104d82},\n created = {2022-08-02T01:01:30.267Z},\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:34:34.595Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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 '->' operator (12%). Also, '!' operator is frequently replaced with '(' and ')'.},\n bibtype = {inproceedings},\n author = {Yuki Ueda, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/ISSREW.2017.32},\n booktitle = {Proceedings - 2017 IEEE 28th International Symposium on Software Reliability Engineering Workshops, ISSREW 2017}\n}
\n
\n\n\n
\n 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 '->' operator (12%). Also, '!' operator is frequently replaced with '(' and ')'.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 操作履歴を利用した不具合票自動生成に向けて.\n \n \n \n\n\n \n Shohei Ikeda; Hideshi Sakaguchi; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ウィンターワークショップ. 1 2017.\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 = {2017},\n month = {1},\n id = {f3bbe218-65ac-3549-8a0b-837cc618bf69},\n created = {2022-08-09T01:34:42.243Z},\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-09T01:34:42.243Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Shohei Ikeda, undefined and Hideshi Sakaguchi, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ウィンターワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 継続的インテグレーションを導入しているOSSのテスト結果の信頼性の検証.\n \n \n \n\n\n \n Tomotaka Minami; Hideshi Sakaguchi; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ウィンターワークショップ. 1 2017.\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 = {継続的インテグレーションを導入しているOSSのテスト結果の信頼性の検証},\n type = {article},\n year = {2017},\n month = {1},\n id = {4b55ce8c-ea00-3acc-bec9-0a876e6ce30c},\n created = {2022-08-09T01:34:49.350Z},\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-09T01:34:49.350Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Tomotaka Minami, undefined and Hideshi Sakaguchi, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ウィンターワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n レビューア間の合意形成と不具合修正に関する一考察〜OpenStackプロジェクトを対象としたケーススタディ〜.\n \n \n \n\n\n \n Hironori Hayashi; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会論文誌. 3 2017.\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 = {レビューア間の合意形成と不具合修正に関する一考察〜OpenStackプロジェクトを対象としたケーススタディ〜},\n type = {article},\n year = {2017},\n month = {3},\n id = {e625450c-65fb-34dd-b564-a71959d2d398},\n created = {2022-08-09T01:34:58.329Z},\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-09T01:34:58.329Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hironori Hayashi, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会論文誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソフトウェア開発に利用するライブラリが属するカテゴリの分析.\n \n \n \n\n\n \n Daiki Katsuragawa; Akinori Ihara; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 12 2017.\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 = {2017},\n month = {12},\n id = {efa74a7e-6d37-3e09-826e-21df11532c20},\n created = {2022-08-09T01:35:24.063Z},\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-09T01:35:24.063Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Daiki Katsuragawa, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆コードレビューを通して変更依頼されるIf文の分析.\n \n \n \n\n\n \n Yuki Ueda; Akinori Ihara; Toshiki Hirao; Takashi Ishio; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2017.\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]🏆コードレビューを通して変更依頼されるIf文の分析},\n type = {article},\n year = {2017},\n month = {9},\n id = {4427df24-77fe-3ed6-bced-e760ddbbb427},\n created = {2022-08-09T01:35:34.063Z},\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:59:33.473Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Yuki Ueda, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n コーディング規約改定によるコードレビュー中の軽微な変更の分析.\n \n \n \n\n\n \n Yuki Ueda; Akinori Ihara; Toshiki Hirao; Takashi Ishio; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2017.\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 = {2017},\n month = {9},\n id = {bd8d9ddf-6d68-306b-8ea3-ad50cd2544ac},\n created = {2022-08-09T01:35:45.206Z},\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-09T01:35:45.206Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Yuki Ueda, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Takashi Ishio, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n When and Which Version to Adopt a Library: A Case Study on Apache Software Foundation Projects.\n \n \n \n\n\n \n Akinori Ihara; Daiki Fujibayashi; Hirohiko Suwa; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n 6 2017.\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
@misc{\n title = {When and Which Version to Adopt a Library: A Case Study on Apache Software Foundation Projects},\n type = {misc},\n year = {2017},\n month = {6},\n publisher = {IEEE Software Blog},\n id = {29ae9898-882d-3c3d-bdca-4d2db5a41d02},\n created = {2022-08-09T01:35:59.042Z},\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-09T01:35:59.042Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {Akinori Ihara, undefined and Daiki Fujibayashi, undefined and Hirohiko Suwa, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Toward Predicting a Reviewer Not to Ignore Code Review Requests in OSS Development.\n \n \n \n\n\n \n Kenichi Ono; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 3 2017.\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 = {Toward Predicting a Reviewer Not to Ignore Code Review Requests in OSS Development},\n type = {article},\n year = {2017},\n month = {3},\n id = {82182075-b6f8-318a-8509-77ba77914709},\n created = {2022-08-09T01:36:15.368Z},\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-09T01:36:15.368Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kenichi Ono, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, 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 Open Source Software Engineering.\n \n \n \n\n\n \n Akinori Ihara\n\n\n \n\n\n\n 5 2017.\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
@misc{\n title = {Open Source Software Engineering},\n type = {misc},\n year = {2017},\n month = {5},\n publisher = {京都大学情報学研究科通信情報システム専攻 談話会},\n id = {23609162-a149-3662-9928-9eb78cf5839b},\n created = {2022-08-09T01:36:58.689Z},\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-09T01:36:58.689Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {misc},\n author = {Akinori Ihara, undefined}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n GithubにおけるREADME記述項目の分析.\n \n \n \n\n\n \n Shohei Ikeda; Akinori Ihara; Raula Gaikovina Kula; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 12 2017.\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 = {GithubにおけるREADME記述項目の分析},\n type = {article},\n year = {2017},\n month = {12},\n id = {3e30156a-995e-3b1b-9935-2dcdb5cf91fd},\n created = {2022-08-09T01:37:21.526Z},\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-09T01:37:21.526Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Shohei Ikeda, undefined and Akinori Ihara, undefined and Raula Gaikovina Kula, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2016\n \n \n (23)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Project IŜ3: Incentive-based intelligent intervention for smart and sustainable society.\n \n \n \n\n\n \n Yutaka Arakawa; Keiichi Yasumoto; Kenichi Matsumoto; Hideaki Hata; Hirohiko Suwa; Akinori Ihara; and Manato Fujimoto\n\n\n \n\n\n\n In Proceedings - 2016 5th IIAI International Congress on Advanced Applied Informatics, IIAI-AAI 2016, 2016. \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 = {Project IŜ3: Incentive-based intelligent intervention for smart and sustainable society},\n type = {inproceedings},\n year = {2016},\n keywords = {Behavior analysis,Car sharing,Intervention,Social science},\n id = {b9bba797-a8b0-355d-80f9-cbfe6938fba3},\n created = {2022-08-02T00:58:27.760Z},\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:19:43.194Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Yutaka Arakawa, undefined and Keiichi Yasumoto, undefined and Kenichi Matsumoto, undefined and Hideaki Hata, undefined and Hirohiko Suwa, undefined and Akinori Ihara, undefined and Manato Fujimoto, undefined},\n doi = {10.1109/IIAI-AAI.2016.97},\n booktitle = {Proceedings - 2016 5th IIAI International Congress on Advanced Applied Informatics, IIAI-AAI 2016}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n The impact of a low level of agreement among reviewers in a code review process.\n \n \n \n\n\n \n Toshiki Hirao; Akinori Ihara; Yuki Ueda; Passakorn Phannachitta; and Kenichi Matsumoto\n\n\n \n\n\n\n Volume 472 2016.\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 = {The impact of a low level of agreement among reviewers in a code review process},\n type = {book},\n year = {2016},\n source = {IFIP Advances in Information and Communication Technology},\n keywords = {Agreement,Modern code review,Software development},\n volume = {472},\n id = {d4f10226-035b-33ed-9185-29c98226751a},\n created = {2022-08-02T01:00:47.976Z},\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:26:56.968Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {book},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Yuki Ueda, undefined and Passakorn Phannachitta, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/978-3-319-39225-7_8}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n A Study of Redundant Metrics in Defect Prediction Datasets.\n \n \n \n\n\n \n Jirayus Jirapakdee; Chakkrit Tantithamathavorn; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 2016 IEEE 27th International Symposium on Software Reliability Engineering Workshops, ISSREW 2016, 2016. \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 = {A Study of Redundant Metrics in Defect Prediction Datasets},\n type = {inproceedings},\n year = {2016},\n keywords = {Defect prediction models,Redundant metrics,Software quality assurance},\n id = {fd792b69-87e0-30ff-b35f-d5fa6f3aa664},\n created = {2022-08-02T01:00:58.671Z},\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-19T04:43:25.720Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Jirayus Jirapakdee, undefined and Chakkrit Tantithamathavorn, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/ISSREW.2016.30},\n booktitle = {Proceedings - 2016 IEEE 27th International Symposium on Software Reliability Engineering Workshops, ISSREW 2016}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Understanding question quality through affective aspect in Q&A site.\n \n \n \n\n\n \n Jirayus Jiarpakdee; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 1st International Workshop on Emotion Awareness in Software Engineering, SEmotion 2016, 2016. \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
@inproceedings{\n title = {Understanding question quality through affective aspect in Q&amp;A site},\n type = {inproceedings},\n year = {2016},\n id = {89084d56-dd11-3be4-bd68-3623debddfce},\n created = {2022-08-02T01:00:59.581Z},\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:34:12.860Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Jirayus Jiarpakdee, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/2897000.2897006},\n booktitle = {Proceedings - 1st International Workshop on Emotion Awareness in Software Engineering, SEmotion 2016}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Code review participation: Game theoretical modeling of reviewers in gerrit datasets.\n \n \n \n\n\n \n Norihiko Kitagawa; Hideaki Hata; Akinori Ihara; Kiminao Kogiso; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 9th International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE 2016, 2016. \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 = {Code review participation: Game theoretical modeling of reviewers in gerrit datasets},\n type = {inproceedings},\n year = {2016},\n keywords = {Code review,Empirical Study,Game Theory},\n id = {201d030c-6555-339e-a30d-99e9d93060e7},\n created = {2022-08-02T01:01:05.994Z},\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:15:26.180Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Norihiko Kitagawa, undefined and Hideaki Hata, undefined and Akinori Ihara, undefined and Kiminao Kogiso, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/2897586.2897605},\n booktitle = {Proceedings - 9th International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE 2016}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 欠陥とソースコードの変更回数の関係分析.\n \n \n \n\n\n \n Kiyoshi Honda; Hideshi Sakaguchzawa; Akinori Ihara; Hironori Washizaki; and Yoshiaki Fukazawa\n\n\n \n\n\n\n ウィンターワークショップ. 1 2016.\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 = {2016},\n month = {1},\n id = {81b2dd05-3deb-322f-82a8-df8cd2821da9},\n created = {2022-08-09T01:34:48.210Z},\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:14:27.803Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kiyoshi Honda, undefined and Hideshi Sakaguchzawa, undefined and Akinori Ihara, undefined and Hironori Washizaki, undefined and Yoshiaki Fukazawa, undefined},\n journal = {ウィンターワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n プロダクトコード変更に伴い共進化するテストコード特定手法の提案.\n \n \n \n\n\n \n Tomotaka Minami; Akinori Ihara; Hideshi Sakaguchi; and Kenichi Matsumoto\n\n\n \n\n\n\n ウィンターワークショップ. 1 2016.\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 = {2016},\n month = {1},\n id = {4be62c76-88da-310f-90db-dfba4d619816},\n created = {2022-08-09T01:35:06.223Z},\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-09T01:35:06.223Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Tomotaka Minami, undefined and Akinori Ihara, undefined and Hideshi Sakaguchi, undefined and Kenichi Matsumoto, undefined},\n journal = {ウィンターワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソフトウェア工学分野における公開データとその活用 -ソフトウェア検証に関する公開データについて-.\n \n \n \n\n\n \n Takuto Norikane; Akinori Ihara; Toshiki Hirao; and Kenichi Matsumoto\n\n\n \n\n\n\n 電子情報通信学会技術研究報告(PRMU, パターン認識・メディア理解). 10 2016.\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 = {2016},\n month = {10},\n id = {19264d93-062f-37c9-b1f8-7411df615b9a},\n created = {2022-08-09T01:35:21.861Z},\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-09T01:35:21.861Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Takuto Norikane, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Kenichi Matsumoto, undefined},\n journal = {電子情報通信学会技術研究報告(PRMU, パターン認識・メディア理解)}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソフトウェア開発記録の多次元データ分析に向けた可視化方式Treemap Forestの設計と実証的評価.\n \n \n \n\n\n \n Takao Nakagawa; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n SEC journal. 7 2016.\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 = {ソフトウェア開発記録の多次元データ分析に向けた可視化方式Treemap Forestの設計と実証的評価},\n type = {article},\n year = {2016},\n month = {7},\n id = {38b48cbc-6d92-3e0e-a2b0-9a13abb6dbd8},\n created = {2022-08-09T01:35:23.024Z},\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-09T01:35:23.024Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Takao Nakagawa, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {SEC 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 Toshiki Hirao; Akinori Ihara; Shane McIntosh; and Kenichi Matsumoto\n\n\n \n\n\n\n IPSJ GN. 9 2016.\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 = {2016},\n month = {9},\n id = {6f1cf453-f0a4-3e3e-a37e-eefabcc476ad},\n created = {2022-08-09T01:35:37.570Z},\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:58:49.498Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Shane McIntosh, undefined and Kenichi Matsumoto, undefined},\n journal = {IPSJ GN}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n コードレビューにおける誤評価する検証者の特定に向けて.\n \n \n \n\n\n \n Toshiki Hirao; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n IPSJ GN. 11 2016.\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 = {2016},\n month = {11},\n id = {947ca541-a213-3a34-845b-4c0492284b01},\n created = {2022-08-09T01:35:39.788Z},\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-09T01:35:39.788Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = { IPSJ GN}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n コードレビューアの指摘記録に基づく開発者の実装技術の成長に関する調査.\n \n \n \n\n\n \n Takuto Norikane; Akinori Ihara; Toshiki Hirao; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2016.\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 = {2016},\n month = {9},\n id = {d1603f16-eb5a-34b0-8d84-a981d476d2cf},\n created = {2022-08-09T01:35:43.171Z},\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-09T01:35:43.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 = {Takuto Norikane, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n オープンソース開発におけるパッチ検証者数の予測.\n \n \n \n\n\n \n Kenichi Ono; Akinori Ihara; Toshiki Hirao; and Kenichi Matsumoto\n\n\n \n\n\n\n ウィンターワークショップ. 1 2016.\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 = {2016},\n month = {1},\n id = {2a90430f-1c9d-371c-805f-1cf326798dd2},\n created = {2022-08-09T01:35:50.633Z},\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-09T01:35:50.633Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kenichi Ono, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Kenichi Matsumoto, undefined},\n journal = {ウィンターワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n オープンソースソフトウェア工学.\n \n \n \n\n\n \n Akinori Ihara; and Masao Ohira\n\n\n \n\n\n\n コンピュータソフトウェア. 1 2016.\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 = {2016},\n month = {1},\n id = {301c83f9-1a6a-3a26-bc8a-365854f1819e},\n created = {2022-08-09T01:35:52.698Z},\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-09T01:35:52.698Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined},\n journal = {コンピュータソフトウェア}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n オープンソースソフトウェア開発における変更行数とリリースの関係分析に向けて.\n \n \n \n\n\n \n Kiyoshi Honda; Akinori Ihara; Hironori Washizaki; and Yoshiaki Fukazawa\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2016.\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 = {2016},\n month = {9},\n id = {96ec0c39-aedd-3602-9068-2bf730063855},\n created = {2022-08-09T01:35:54.988Z},\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-09T01:35:54.988Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kiyoshi Honda, undefined and Akinori Ihara, undefined and Hironori Washizaki, undefined and Yoshiaki Fukazawa, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n What Additional Features Should Be in a High-Impact Bug Report?.\n \n \n \n\n\n \n Md.Rejaul Karim; Akinori Ihara; Xin Yang; Hajimu Iida; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 3 2016.\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 = {What Additional Features Should Be in a High-Impact Bug Report?},\n type = {article},\n year = {2016},\n month = {3},\n id = {c0448b9c-5a04-3ca2-9ff0-23b8b406678b},\n created = {2022-08-09T01:36:02.099Z},\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-09T01:36:02.099Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Md.Rejaul Karim, undefined and Akinori Ihara, undefined and Xin Yang, undefined and Hajimu Iida, undefined and Kenichi Matsumoto, 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 Towards a Better Reviewer Recommendation Using the Level of Agreement.\n \n \n \n\n\n \n Toshiki Hirao; Akinori Ihara; Yuki Ueda; and Passakorn Phannachitta\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 3 2016.\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 = {Towards a Better Reviewer Recommendation Using the Level of Agreement},\n type = {article},\n year = {2016},\n month = {3},\n id = {791b1a66-d57b-3b6d-a005-08d0cd9a6b00},\n created = {2022-08-09T01:36:13.038Z},\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-09T01:36:13.038Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Yuki Ueda, undefined and Passakorn Phannachitta, 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 Toward Selecting a Reliable Version of OSS Library Based on Bug-Fixing Curve.\n \n \n \n\n\n \n Keisuke Fujino; Akinori Ihara; Kiyoshi Honda; Hironori Washizaki; and Kenichi Matsumoto\n\n\n \n\n\n\n The 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering. 3 2016.\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 = {Toward Selecting a Reliable Version of OSS Library Based on Bug-Fixing Curve},\n type = {article},\n year = {2016},\n month = {3},\n id = {af5ea224-070b-3706-a64e-fd397db5f69b},\n created = {2022-08-09T01:36:14.236Z},\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-09T01:36:14.236Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Keisuke Fujino, undefined and Akinori Ihara, undefined and Kiyoshi Honda, undefined and Hironori Washizaki, undefined and Kenichi Matsumoto, undefined},\n journal = {The 24th IEEE International Conference on Software Analysis, Evolution, and Reengineering}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Toward Identifying Responders to a Code Review Request -Case Study of Qt Project-.\n \n \n \n\n\n \n Kenichi Ono; Akinori Ihara; Toshiki Hirao; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 3 2016.\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 = {Toward Identifying Responders to a Code Review Request -Case Study of Qt Project-},\n type = {article},\n year = {2016},\n month = {3},\n id = {62255202-ed32-37ee-a933-2dd30ce4543e},\n created = {2022-08-09T01:36:18.841Z},\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-09T01:36:18.841Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kenichi Ono, undefined and Akinori Ihara, undefined and Toshiki Hirao, undefined and Kenichi Matsumoto, 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 OSS開発のコードレビュー依頼に貢献する開発者の予測.\n \n \n \n\n\n \n Kenichi Ono; Akinori Ihara; Hideshi Sakaguchi; and Toshiki Hirao\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 12 2016.\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 = {OSS開発のコードレビュー依頼に貢献する開発者の予測},\n type = {article},\n year = {2016},\n month = {12},\n id = {bcd327fa-ad66-3af8-b7cd-d4bccdb13e34},\n created = {2022-08-09T01:36:43.199Z},\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-09T01:36:43.199Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kenichi Ono, undefined and Akinori Ihara, undefined and Hideshi Sakaguchi, undefined and Toshiki Hirao, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発におけるパッチの特徴量を用いた再投稿要求の予測.\n \n \n \n\n\n \n Satoshi Ando; Akinori Ihara; Hiroyuki Seki; Toshiki Hirao; Takuto Norikane; and Kenichi Matsumoto\n\n\n \n\n\n\n IPSJ SE. 11 2016.\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 = {OSS開発におけるパッチの特徴量を用いた再投稿要求の予測},\n type = {article},\n year = {2016},\n month = {11},\n id = {05e91a1b-8ae2-3b68-8cc2-c475d8402de3},\n created = {2022-08-09T01:36:47.852Z},\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-09T01:36:47.852Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Satoshi Ando, undefined and Akinori Ihara, undefined and Hiroyuki Seki, undefined and Toshiki Hirao, undefined and Takuto Norikane, undefined and Kenichi Matsumoto, undefined},\n journal = {IPSJ SE}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発におけるソースコード静的解析手法を用いたパッチ検証手法の提案.\n \n \n \n\n\n \n Satoshi Ando; Toshiki Hirao; Akinori Ihara; Kenichi Matsumoto; and Hiroyuki Seki\n\n\n \n\n\n\n ウィンターワークショップ. 1 2016.\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 = {OSS開発におけるソースコード静的解析手法を用いたパッチ検証手法の提案},\n type = {article},\n year = {2016},\n month = {1},\n id = {bf63bf60-2c0c-388a-9e02-cb90fcd913e3},\n created = {2022-08-09T01:36:50.266Z},\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-09T01:36:50.266Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Satoshi Ando, undefined and Toshiki Hirao, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined and Hiroyuki Seki, undefined},\n journal = {ウィンターワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSライブラリを利用するシステムのリリースサイクルに着目したライブラリの導入時期の調査.\n \n \n \n\n\n \n Hirohiko Suwa; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2016.\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 = {OSSライブラリを利用するシステムのリリースサイクルに着目したライブラリの導入時期の調査},\n type = {article},\n year = {2016},\n month = {9},\n id = {60867a42-aae2-385c-9853-e1b0f9a80e37},\n created = {2022-08-09T01:36:51.334Z},\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-09T01:36:51.334Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hirohiko Suwa, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2015\n \n \n (17)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n A dataset of high impact bugs: Manually-classified issue reports.\n \n \n \n\n\n \n Masao Ohira; Yutaro Kashiwa; Yosuke Yamatani; Hayato Yoshiyuki; Yoshiya Maeda; Nachai Limsettho; Keisuke Fujino; Hideaki Hata; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In IEEE International Working Conference on Mining Software Repositories, volume 2015-Augus, 2015. \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\n\n\n
\n
@inproceedings{\n title = {A dataset of high impact bugs: Manually-classified issue reports},\n type = {inproceedings},\n year = {2015},\n keywords = {Computer bugs,Data mining,Labeling,Manuals,Security,Software systems},\n volume = {2015-Augus},\n id = {521bebc0-5afc-3026-8790-60b592c7773e},\n created = {2022-08-02T01:01:12.148Z},\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-19T04:41:37.697Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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).},\n bibtype = {inproceedings},\n author = {Masao Ohira, undefined and Yutaro Kashiwa, undefined and Yosuke Yamatani, undefined and Hayato Yoshiyuki, undefined and Yoshiya Maeda, undefined and Nachai Limsettho, undefined and Keisuke Fujino, undefined and Hideaki Hata, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/MSR.2015.78},\n booktitle = {IEEE International Working Conference on Mining Software Repositories}\n}
\n
\n\n\n
\n 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).\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n The impact of mislabelling on the performance and interpretation of defect prediction models.\n \n \n \n\n\n \n Chakkrit Tantithamthavorn; Shane McIntosh; Ahmed E. Hassan; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - International Conference on Software Engineering, volume 1, 2015. \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
@inproceedings{\n title = {The impact of mislabelling on the performance and interpretation of defect prediction models},\n type = {inproceedings},\n year = {2015},\n volume = {1},\n id = {039fca79-02a2-370d-99a0-b15db62ea231},\n created = {2022-08-02T01:01:22.637Z},\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:31:07.137Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Chakkrit Tantithamthavorn, undefined and Shane McIntosh, undefined and Ahmed E. Hassan, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/ICSE.2015.93},\n booktitle = {Proceedings - International Conference on Software Engineering}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n パッチ開発のための不具合報告内容の分析.\n \n \n \n\n\n \n Hiroki Kawai; Akinori Ihara; Hideshi Sakaguchi; Takao Nakagawa; and Keisuke Fujino\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2015.\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 = {2015},\n month = {9},\n id = {005b8516-82fc-327c-aadb-9185e5baa02d},\n created = {2022-08-09T01:35:10.319Z},\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-09T01:35:10.319Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hiroki Kawai, undefined and Akinori Ihara, undefined and Hideshi Sakaguchi, undefined and Takao Nakagawa, undefined and Keisuke Fujino, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n データサイズを考慮したコミッター候補者予測モデルの検討.\n \n \n \n\n\n \n Akira Matsumoto; Akinori Ihara; and Masao Ohira\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2015.\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 = {2015},\n month = {9},\n id = {d0b341c0-ee6c-3f64-b6fb-1dc04661631a},\n created = {2022-08-09T01:35:12.341Z},\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-09T01:35:12.341Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akira Matsumoto, undefined and Akinori Ihara, undefined and Masao Ohira, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソースコードの変更回数と不具合修正の関係分析に向けて.\n \n \n \n\n\n \n Kiyoshi Honda; Akinori Ihara; Hironori Washizaki; and Yoshiaki Fukazawa\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2015.\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 = {2015},\n month = {9},\n id = {12620cf8-12fd-3d9a-91d6-8b2ba5f5ac71},\n created = {2022-08-09T01:35:28.554Z},\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-09T01:35:28.554Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kiyoshi Honda, undefined and Akinori Ihara, undefined and Hironori Washizaki, undefined and Yoshiaki Fukazawa, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n コードレビュープロセスに基づくパッチ再投稿の予測.\n \n \n \n\n\n \n Toshiki Hirao; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2015.\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 = {2015},\n month = {9},\n id = {c0cea720-b6e3-378f-acf9-1634922983f2},\n created = {2022-08-09T01:35:36.467Z},\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-09T01:35:36.467Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n コードレビューのジレンマ/スノードリフトゲームによる協調行動の分析.\n \n \n \n\n\n \n Norihiko Kitagawa; Hideaki Hata; Akinori Ihara; Kiminao Kogiso; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 11 2015.\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 = {2015},\n month = {11},\n id = {8f589c1d-f549-3ac5-ae9b-66041d7cc4e1},\n created = {2022-08-09T01:35:38.669Z},\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-09T01:35:38.669Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Norihiko Kitagawa, undefined and Hideaki Hata, undefined and Akinori Ihara, undefined and Kiminao Kogiso, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n コードクローンと使用ライブラリに着目したオープンソースソフトウェアの進化の定量化.\n \n \n \n\n\n \n Kota Wakabayashi; Akito Monden; Akinori Ihara; and Haruki Tamada\n\n\n \n\n\n\n 研究報告ソフトウェア工学(SE). 12 2015.\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 = {2015},\n month = {12},\n id = {071c6688-7bd9-3181-96d0-ac05fc74c90d},\n created = {2022-08-09T01:35:44.220Z},\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-09T01:35:44.220Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kota Wakabayashi, undefined and Akito Monden, undefined and Akinori Ihara, undefined and Haruki Tamada, undefined},\n journal = {研究報告ソフトウェア工学(SE)}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n オープンソースソフトウェアにおけるテストコードの保守頻度と生存期間の分析.\n \n \n \n\n\n \n Hideshi Sakaguchi; Tomotaka Minami; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n 研究報告ソフトウェア工学(SE). 12 2015.\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 = {2015},\n month = {12},\n id = {eac6fc97-aab2-32ba-b7bc-1c6a498d2828},\n created = {2022-08-09T01:35:55.965Z},\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-09T01:35:55.965Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hideshi Sakaguchi, undefined and Tomotaka Minami, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {研究報告ソフトウェア工学(SE)}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n The Impact of Maintenance Frequency of Test Codes on the Defect Detection in OSS Development.\n \n \n \n\n\n \n Hideshi Sakaguchi; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n MSR Asia Summit. 10 2015.\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 = {The Impact of Maintenance Frequency of Test Codes on the Defect Detection in OSS Development},\n type = {article},\n year = {2015},\n month = {10},\n id = {05cefa8f-79d6-32e4-8359-6277ee159e26},\n created = {2022-08-09T01:36:22.925Z},\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-09T01:36:22.925Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hideshi Sakaguchi, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {MSR Asia Summit}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Pilot Study of Collective Decision-Making in the Code Review Process.\n \n \n \n\n\n \n Toshiki Hirao; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n The Center for Advanced Studies on Collaborative ResearchT. 11 2015.\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 = {Pilot Study of Collective Decision-Making in the Code Review Process},\n type = {article},\n year = {2015},\n month = {11},\n id = {95d27b25-533f-33bd-adb5-5eb17980edb9},\n created = {2022-08-09T01:36:39.348Z},\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-09T01:36:39.348Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {The Center for Advanced Studies on Collaborative ResearchT}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発のプロジェクト事情による不具合修正時間の分析.\n \n \n \n\n\n \n Ryoki Wakamoto; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2015.\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 = {OSS開発のプロジェクト事情による不具合修正時間の分析},\n type = {article},\n year = {2015},\n month = {7},\n id = {fbbdb8b1-4e89-3c52-a8b5-9821f743f9be},\n created = {2022-08-09T01:36:41.901Z},\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-09T01:36:41.901Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Ryoki Wakamoto, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発におけるテストコードの保守頻度 が与える欠陥混入への影響.\n \n \n \n\n\n \n Hideshi Sakaguchi; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2015.\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 = {OSS開発におけるテストコードの保守頻度 が与える欠陥混入への影響},\n type = {article},\n year = {2015},\n month = {9},\n id = {7fe922da-6204-37a3-8ad9-46e96bc36f95},\n created = {2022-08-09T01:36:49.066Z},\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-09T01:36:49.066Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hideshi Sakaguchi, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSプロジェクトの開発状況が不具合対応時間に与える影響.\n \n \n \n\n\n \n Ryoki Wakamoto; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2015.\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 = {OSSプロジェクトの開発状況が不具合対応時間に与える影響},\n type = {article},\n year = {2015},\n month = {9},\n id = {343c0d81-7c53-37e4-8053-00161b40c6e9},\n created = {2022-08-09T01:36:52.345Z},\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-09T01:36:52.345Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Ryoki Wakamoto, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSシステムとコミュニティの共進化の理解を目的としたデータマイニング手法.\n \n \n \n\n\n \n Yosuke Yamatani; Masao Ohira; Passakorn Phannachitta; and Akinori Ihara\n\n\n \n\n\n\n 情報処理学会論文誌. 1 2015.\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 = {OSSシステムとコミュニティの共進化の理解を目的としたデータマイニング手法},\n type = {article},\n year = {2015},\n month = {1},\n id = {4f6b8950-833b-3902-8207-fade7c4905b2},\n created = {2022-08-09T01:36:55.453Z},\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-09T01:36:55.453Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Yosuke Yamatani, undefined and Masao Ohira, undefined and Passakorn Phannachitta, undefined and Akinori Ihara, undefined},\n journal = {情報処理学会論文誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n How do core reviewers make a decision in Code Review Process -­‐ A Pilot Study of Open Source Project Patches -­‐.\n \n \n \n\n\n \n Toshiki Hirao; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n MSR Asia Summit. 10 2015.\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 = {How do core reviewers make a decision in Code Review Process -­‐ A Pilot Study of Open Source Project Patches -­‐},\n type = {article},\n year = {2015},\n month = {10},\n id = {0397e429-5837-3118-beba-ad17cf227180},\n created = {2022-08-09T01:37:17.228Z},\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-09T01:37:17.228Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Toshiki Hirao, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {MSR Asia Summit}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n A Theoretical and Empirical Study of Cooperation in Code Review.\n \n \n \n\n\n \n Norihiko Kitagawa; Hideaki Hata; Akinori Ihara; Kenichi Matsumoto; and Kiminao Kogiso\n\n\n \n\n\n\n MSR Asia Summit. 10 2015.\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 = {A Theoretical and Empirical Study of Cooperation in Code Review},\n type = {article},\n year = {2015},\n month = {10},\n id = {d23bd32d-c260-385a-9479-3f20e6991903},\n created = {2022-08-09T01:37:48.129Z},\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-09T01:37:48.129Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Norihiko Kitagawa, undefined and Hideaki Hata, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined and Kiminao Kogiso, undefined},\n journal = {MSR Asia Summit}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2014\n \n \n (14)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Industry questions about open source software in business: Research directions and potential answers.\n \n \n \n\n\n \n Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 2014 6th International Workshop on Empirical Software Engineering in Practice, IWESEP 2014, 2014. \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 = {Industry questions about open source software in business: Research directions and potential answers},\n type = {inproceedings},\n year = {2014},\n keywords = {Industry Software Engineering,Mining Software Repository,Open Source Software},\n id = {1643401d-946b-3be0-a0ff-2297fb99b837},\n created = {2022-08-02T01:00:50.884Z},\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:52.108Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/IWESEP.2014.12},\n booktitle = {Proceedings - 2014 6th International Workshop on Empirical Software Engineering in Practice, IWESEP 2014}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Early identification of future committers in open source software projects.\n \n \n \n\n\n \n Akinori Ihara; Yasutaka Kamei; Masao Ohira; Ahmed E. Hassan; Naoyasu Ubayashi; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - International Conference on Quality Software, 2014. \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
@inproceedings{\n title = {Early identification of future committers in open source software projects},\n type = {inproceedings},\n year = {2014},\n id = {9931ba3c-82d8-35de-833c-c3a17e389ae0},\n created = {2022-08-02T01:00:51.882Z},\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:29:23.911Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Akinori Ihara, undefined and Yasutaka Kamei, undefined and Masao Ohira, undefined and Ahmed E. Hassan, undefined and Naoyasu Ubayashi, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/QSIC.2014.30},\n booktitle = {Proceedings - International Conference on Quality Software}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Do open source software projects conduct tests enough?.\n \n \n \n\n\n \n Ryohei Takasawa; Kazunori Sakamoto; Akinori Ihara; Hironori Washizaki; and Yoshiaki Fukazawa\n\n\n \n\n\n\n Volume 8892 2014.\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
@book{\n title = {Do open source software projects conduct tests enough?},\n type = {book},\n year = {2014},\n source = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},\n volume = {8892},\n id = {499608ad-b3f6-364d-ae5f-0fcf4f186f5f},\n created = {2022-08-02T01:01:20.892Z},\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:18:16.136Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Do open source software projects provide and maintain tests? What metrics are correlated with the test success? This paper answers these questions by executing tests of 452 open source software projects in GitHub and measuring 13 metrics from 77 projects. Only 117 projects passed all test cases. Additionally, the results are correlated with the comment density, public documented API density, and test coverage.},\n bibtype = {book},\n author = {Ryohei Takasawa, undefined and Kazunori Sakamoto, undefined and Akinori Ihara, undefined and Hironori Washizaki, undefined and Yoshiaki Fukazawa, undefined},\n doi = {10.1007/978-3-319-13835-0_32}\n}
\n
\n\n\n
\n Do open source software projects provide and maintain tests? What metrics are correlated with the test success? This paper answers these questions by executing tests of 452 open source software projects in GitHub and measuring 13 metrics from 77 projects. Only 117 projects passed all test cases. Additionally, the results are correlated with the comment density, public documented API density, and test coverage.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Impact Analysis of Granularity Levels on Feature Location Technique.\n \n \n \n\n\n \n Chakkrit Tantithamathavorn; Akinori Ihara; Hideaki Hata; and Kenichi Matsumoto\n\n\n \n\n\n\n Volume 432 CCIS 2014.\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 = {Impact Analysis of Granularity Levels on Feature Location Technique},\n type = {book},\n year = {2014},\n source = {Communications in Computer and Information Science},\n keywords = {Effort-Based Evaluation,Feature Location,Granularity Level},\n volume = {432 CCIS},\n id = {7ce4d29a-0190-3847-9607-3628008ba5bc},\n created = {2022-08-02T01:01:23.811Z},\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:38:49.658Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {book},\n author = {Chakkrit Tantithamathavorn, undefined and Akinori Ihara, undefined and Hideaki Hata, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/978-3-662-43610-3_11}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 複数のオープンソースプロジェクトに参加する開発者による貢献の分析.\n \n \n \n\n\n \n Hideshi Sakaguchi; Akinori Ihara; Saya Onoue; Hideaki Hata; and Kenichi Matsumoto\n\n\n \n\n\n\n 第92回GN・第9回SPT合同研究発表会. 5 2014.\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 = {2014},\n month = {5},\n id = {1d06aa93-22de-3a22-9200-d85e5e56e70b},\n created = {2022-08-09T01:34:40.263Z},\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-09T01:34:40.263Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hideshi Sakaguchi, undefined and Akinori Ihara, undefined and Saya Onoue, undefined and Hideaki Hata, undefined and Kenichi Matsumoto, undefined},\n journal = {第92回GN・第9回SPT合同研究発表会}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n パッチレビュープロセスにおけるパッチ作成者の継続性の違い.\n \n \n \n\n\n \n Ataru Osaka; Akinori Ihara; Yasutaka Kamei; Kenichi Matsumoto; and Naoyasu Ubayashi\n\n\n \n\n\n\n 情報処理学会研究報告. 5 2014.\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 = {2014},\n month = {5},\n id = {ab3075bd-8c6c-3317-8e8e-6be7b0181a2e},\n created = {2022-08-09T01:35:11.344Z},\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-09T01:35:11.344Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Ataru Osaka, undefined and Akinori Ihara, undefined and Yasutaka Kamei, undefined and Kenichi Matsumoto, undefined and Naoyasu Ubayashi, undefined},\n journal = {情報処理学会研究報告}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n ソフトウェア品質の第三者評価における探索的データ解析ツールの利用とその効果:OSSデータを対象とした検証実験.\n \n \n \n\n\n \n Masao Ohira; Akinori Ihara; Daisuke Nakano; and Kenichi Matsumoto\n\n\n \n\n\n\n SEC journal. 3 2014.\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 = {ソフトウェア品質の第三者評価における探索的データ解析ツールの利用とその効果:OSSデータを対象とした検証実験},\n type = {article},\n year = {2014},\n month = {3},\n id = {834a2327-bbcc-36a7-87c7-c56f26ce6553},\n created = {2022-08-09T01:35:19.703Z},\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-09T01:35:19.703Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Masao Ohira, undefined and Akinori Ihara, undefined and Daisuke Nakano, undefined and Kenichi Matsumoto, undefined},\n journal = {SEC journal}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n オープンソースプロジェクト特性 に基づくバグ収束過程の理解.\n \n \n \n\n\n \n Hideshi Sakaguchi; Shade Ruangwan; Akinori Ihara; Rungsawang Arnon; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2014.\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 = {2014},\n month = {7},\n id = {63ff6057-0fd5-358c-9cc3-682611531aa5},\n created = {2022-08-09T01:35:51.609Z},\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-09T01:35:51.609Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hideshi Sakaguchi, undefined and Shade Ruangwan, undefined and Akinori Ihara, undefined and Rungsawang Arnon, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Understanding Important Factors to Identify Good and Bad Questions : a Case Study of Stackoverflow.\n \n \n \n\n\n \n Jirayus Jirapakdee; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In 11 2014. \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
@inproceedings{\n title = {Understanding Important Factors to Identify Good and Bad Questions : a Case Study of Stackoverflow},\n type = {inproceedings},\n year = {2014},\n month = {11},\n id = {edf01c08-f60f-394b-b98f-3e381212e3d2},\n created = {2022-08-09T01:36:09.751Z},\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-09T01:36:09.751Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {inproceedings},\n author = {Jirayus Jirapakdee, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆Toward Monitoring Bugs-Fixing Process After the Releases in Open Source Software.\n \n \n \n\n\n \n Keisuke Fujino; Akinori Ihara; Kiyoshi Honda; Hironori Washizaki; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 11 2014.\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]🏆Toward Monitoring Bugs-Fixing Process After the Releases in Open Source Software},\n type = {article},\n year = {2014},\n month = {11},\n id = {835f5768-ee83-3964-82e3-78e841751363},\n created = {2022-08-09T01:36:16.573Z},\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:57:04.001Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Keisuke Fujino, undefined and Akinori Ihara, undefined and Kiyoshi Honda, undefined and Hironori Washizaki, undefined and Kenichi Matsumoto, 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 Toward Identifying Future Committers Based on Developers Communication.\n \n \n \n\n\n \n Ryoki Wakamoto; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 11 2014.\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 = {Toward Identifying Future Committers Based on Developers Communication},\n type = {article},\n year = {2014},\n month = {11},\n id = {d050e24f-4c9b-39c4-b013-b55403dd365f},\n created = {2022-08-09T01:36:19.924Z},\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-09T01:36:19.924Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Ryoki Wakamoto, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, 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 OSSプロジェクトにおけるコミッターの承認に対する動機の理解.\n \n \n \n\n\n \n Akinori Ihara; Yasutaka Kamei; Masao Ohira; Bram Adams; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 12 2014.\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 = {OSSプロジェクトにおけるコミッターの承認に対する動機の理解},\n type = {article},\n year = {2014},\n month = {12},\n id = {7098f664-17ec-3d9a-b265-3744dc32b8d6},\n created = {2022-08-09T01:36:53.449Z},\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-09T01:36:53.449Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Yasutaka Kamei, undefined and Masao Ohira, undefined and Bram Adams, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSの不具合修正曲線に基づく未修正不具合数の予測の試み.\n \n \n \n\n\n \n Keisuke Fujino; Akinori Ihara; Kiyoshi Honda; Hironori Washizaki; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 12 2014.\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 = {OSSの不具合修正曲線に基づく未修正不具合数の予測の試み},\n type = {article},\n year = {2014},\n month = {12},\n id = {9b2264f5-5f1b-3774-bbe5-61e3ce77812b},\n created = {2022-08-09T01:36:54.497Z},\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-09T01:36:54.497Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Keisuke Fujino, undefined and Akinori Ihara, undefined and Kiyoshi Honda, undefined and Hironori Washizaki, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Adaptive Search Framework: Better Search Result for Community.\n \n \n \n\n\n \n Papon Yongpisanpop; Masao Ohira; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In 情報社会学会誌, 3 2014. \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
@inproceedings{\n title = {Adaptive Search Framework: Better Search Result for Community},\n type = {inproceedings},\n year = {2014},\n month = {3},\n id = {072f4d5e-e14a-3bde-9cd5-8a0f034d282a},\n created = {2022-08-09T01:37:45.847Z},\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-09T01:37:45.847Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {inproceedings},\n author = {Papon Yongpisanpop, undefined and Masao Ohira, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n booktitle = {情報社会学会誌}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2013\n \n \n (21)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Why is collaboration needed in OSS projects? A case study of eclipse project.\n \n \n \n\n\n \n Hironori Hayashi; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n In 2013 5th International Workshop on Social Software Engineering, SSE 2013 - Proceedings, 2013. \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 = {Why is collaboration needed in OSS projects? A case study of eclipse project},\n type = {inproceedings},\n year = {2013},\n keywords = {Collaboration,Open source software development,Re-open},\n id = {beec3e53-f19c-36b2-8e7f-0e1f6cc408e3},\n created = {2022-08-02T01:00:44.256Z},\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:32:57.180Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {In open source software development, the collaboration among developers is the key to improve software quality. In particular, to fix a bug related to various parts of a system, developers need collaboration because each developer usually has very limited knowledge about a large software system. This paper aims to clarify how narrow (or how wide) is each developer's knowledge area in the Eclipse project, and how often do developers need to collaborate with each other. As a result of analysis, we found that 50 % of committers take care of just one or two modules, which indicates the necessity of collaboration when a bug-fix affects multiple modules. In addition, we also found the significant relationship between committers' collaborations and the re-opened bugs. We conclude that a committer should be aware the risk of re-opened bugs caused by the collaboration. Copyright 2013 ACM.},\n bibtype = {inproceedings},\n author = {Hironori Hayashi, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/2501535.2501539},\n booktitle = {2013 5th International Workshop on Social Software Engineering, SSE 2013 - Proceedings}\n}
\n
\n\n\n
\n In open source software development, the collaboration among developers is the key to improve software quality. In particular, to fix a bug related to various parts of a system, developers need collaboration because each developer usually has very limited knowledge about a large software system. This paper aims to clarify how narrow (or how wide) is each developer's knowledge area in the Eclipse project, and how often do developers need to collaborate with each other. As a result of analysis, we found that 50 % of committers take care of just one or two modules, which indicates the necessity of collaboration when a bug-fix affects multiple modules. In addition, we also found the significant relationship between committers' collaborations and the re-opened bugs. We conclude that a committer should be aware the risk of re-opened bugs caused by the collaboration. Copyright 2013 ACM.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n What type of thread can get feedback in oss user mailing list?.\n \n \n \n\n\n \n Akinori Ihara; Yuji Tsuda; and Kenichi Matsumoto\n\n\n \n\n\n\n In 2013 5th International Workshop on Social Software Engineering, SSE 2013 - Proceedings, 2013. \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 = {What type of thread can get feedback in oss user mailing list?},\n type = {inproceedings},\n year = {2013},\n keywords = {Communication,Open Source Software,User Mailing List},\n id = {9fa05a66-4c0f-3741-8ee1-d4a6748a9945},\n created = {2022-08-02T01:00:52.766Z},\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:36:30.815Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Akinori Ihara, undefined and Yuji Tsuda, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/2501535.2501541},\n booktitle = {2013 5th International Workshop on Social Software Engineering, SSE 2013 - Proceedings}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Patch reviewer recommendation in OSS projects.\n \n \n \n\n\n \n John Boaz Lee; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - Asia-Pacific Software Engineering Conference, APSEC, volume 2, 2013. \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 = {Patch reviewer recommendation in OSS projects},\n type = {inproceedings},\n year = {2013},\n keywords = {CVS,Mining software repositories,Patch reviewer recommendation,Random walk},\n volume = {2},\n id = {402f0ad8-7522-3603-9af4-2827100958f5},\n created = {2022-08-02T01:01:07.759Z},\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:17:15.073Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {In an Open Source Software (OSS) project, many developers contribute by submitting source code patches. To maintain the quality of the code, certain experienced developers review each patch before it can be applied or committed. Ideally, within a short amount of time after its submission, a patch is assigned to a reviewer and reviewed. In the real world, however, many large and active OSS projects evolve at a rapid pace and the core developers can get swamped with a large number of patches to review. Furthermore, since these core members may not always be available or may choose to leave the project, it can be challenging, at times, to find a good reviewer for a patch. In this paper, we propose a graph-based method to automatically recommend the most suitable reviewers for a patch. To evaluate our method, we conducted experiments to predict the developers who will apply new changes to the source code in the Eclipse project. Our method achieved an average recall of 0.84 for top-5 predictions and a recall of 0.94 for top-10 predictions.},\n bibtype = {inproceedings},\n author = {John Boaz Lee, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/APSEC.2013.103},\n booktitle = {Proceedings - Asia-Pacific Software Engineering Conference, APSEC}\n}
\n
\n\n\n
\n In an Open Source Software (OSS) project, many developers contribute by submitting source code patches. To maintain the quality of the code, certain experienced developers review each patch before it can be applied or committed. Ideally, within a short amount of time after its submission, a patch is assigned to a reviewer and reviewed. In the real world, however, many large and active OSS projects evolve at a rapid pace and the core developers can get swamped with a large number of patches to review. Furthermore, since these core members may not always be available or may choose to leave the project, it can be challenging, at times, to find a good reviewer for a patch. In this paper, we propose a graph-based method to automatically recommend the most suitable reviewers for a patch. To evaluate our method, we conducted experiments to predict the developers who will apply new changes to the source code in the Eclipse project. Our method achieved an average recall of 0.84 for top-5 predictions and a recall of 0.94 for top-10 predictions.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Mining software repositories.\n \n \n \n\n\n \n Akito Monden; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n Computer Software, 30(2). 2013.\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 abstract \n \n\n \n\n \n \n \n \n \n \n \n\n  \n \n \n\n\n\n
\n
@article{\n title = {Mining software repositories},\n type = {article},\n year = {2013},\n volume = {30},\n id = {9ba23c5a-20b4-34ee-8844-d42e55bf42e7},\n created = {2022-08-02T01:01:08.742Z},\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-19T06:01:08.562Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {The Mining Software Repositories (MSR) is an attractive research field that has tons of research topics. It is great fun for a researcher to mine new research goals from software repositories. The MSR field has been grown up with OSS communities, as researchers have mined repositories of various open source software (OSS) projects until now. In this paper we introduce fun of the MSR field as well as its typical research topics, example of mining and future directions.},\n bibtype = {article},\n author = {Akito Monden, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {Computer Software},\n number = {2}\n}
\n
\n\n\n
\n The Mining Software Repositories (MSR) is an attractive research field that has tons of research topics. It is great fun for a researcher to mine new research goals from software repositories. The MSR field has been grown up with OSS communities, as researchers have mined repositories of various open source software (OSS) projects until now. In this paper we introduce fun of the MSR field as well as its typical research topics, example of mining and future directions.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Studying re-opened bugs in open source software.\n \n \n \n\n\n \n Emad Shihab; Akinori Ihara; Yasutaka Kamei; Walid M. Ibrahim; Masao Ohira; Bram Adams; Ahmed E. Hassan; and Kenichi Matsumoto\n\n\n \n\n\n\n Empirical Software Engineering, 18(5). 2013.\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 = {Studying re-opened bugs in open source software},\n type = {article},\n year = {2013},\n keywords = {Bug reports,Open source software,Re-opened bugs},\n volume = {18},\n id = {6d4733c4-482f-3de2-84a8-1751200c7a56},\n created = {2022-08-02T01:01:18.170Z},\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:09:13.761Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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 three large open source projects - namely Eclipse, Apache and OpenOffice. We structure our study along four dimensions: (1) the work habits dimension (e.g., the weekday on which the bug was initially closed), (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). We build decision trees using the aforementioned factors that aim to predict re-opened bugs. We perform top node analysis to determine which factors are the most important indicators of whether or not a bug will be re-opened. Our study shows that the comment text and last status of the bug when it is initially closed are the most important factors related to whether or not a bug will be re-opened. Using a combination of these dimensions, we can build explainable prediction models that can achieve a precision between 52.1-78.6 % and a recall in the range of 70.5-94.1 % when predicting whether a bug will be re-opened. We find that the factors that best indicate which bugs might be re-opened vary based on the project. The comment text is the most important factor for the Eclipse and OpenOffice projects, while the last status is the most important one for Apache. These factors should be closely examined in order to reduce maintenance cost due to re-opened bugs. © 2012 Springer Science+Business Media, LLC.},\n bibtype = {article},\n author = {Emad Shihab, undefined and Akinori Ihara, undefined and Yasutaka Kamei, undefined and Walid M. Ibrahim, undefined and Masao Ohira, undefined and Bram Adams, undefined and Ahmed E. Hassan, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/s10664-012-9228-6},\n journal = {Empirical Software Engineering},\n number = {5}\n}
\n
\n\n\n
\n 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 three large open source projects - namely Eclipse, Apache and OpenOffice. We structure our study along four dimensions: (1) the work habits dimension (e.g., the weekday on which the bug was initially closed), (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). We build decision trees using the aforementioned factors that aim to predict re-opened bugs. We perform top node analysis to determine which factors are the most important indicators of whether or not a bug will be re-opened. Our study shows that the comment text and last status of the bug when it is initially closed are the most important factors related to whether or not a bug will be re-opened. Using a combination of these dimensions, we can build explainable prediction models that can achieve a precision between 52.1-78.6 % and a recall in the range of 70.5-94.1 % when predicting whether a bug will be re-opened. We find that the factors that best indicate which bugs might be re-opened vary based on the project. The comment text is the most important factor for the Eclipse and OpenOffice projects, while the last status is the most important one for Apache. These factors should be closely examined in order to reduce maintenance cost due to re-opened bugs. © 2012 Springer Science+Business Media, LLC.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Mining A change history to quickly identify bug locations: A case study of the Eclipse project.\n \n \n \n\n\n \n Chakkrit Tantithamathavorn; Rattamont Teekavanich; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In 2013 IEEE International Symposium on Software Reliability Engineering Workshops, ISSREW 2013, 2013. \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 = {Mining A change history to quickly identify bug locations: A case study of the Eclipse project},\n type = {inproceedings},\n year = {2013},\n keywords = {Bug Localization,Information Retrieval,Mining Change History,Software Debugging},\n id = {19df6e1f-45c6-38c9-a1a8-e688f8cd9b55},\n created = {2022-08-02T01:01:24.718Z},\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:58:12.164Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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. © 2013 IEEE.},\n bibtype = {inproceedings},\n author = {Chakkrit Tantithamathavorn, undefined and Rattamont Teekavanich, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/ISSREW.2013.6688888},\n booktitle = {2013 IEEE International Symposium on Software Reliability Engineering Workshops, ISSREW 2013}\n}
\n
\n\n\n
\n 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. © 2013 IEEE.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Using co-change histories to improve bug localization performance.\n \n \n \n\n\n \n Chakkrit Tantithamthavorn; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n In SNPD 2013 - 14th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, 2013. \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 = {Using co-change histories to improve bug localization performance},\n type = {inproceedings},\n year = {2013},\n keywords = {Bug Localization,Co-Change Histories,Information Retrieval,Software Maintenance},\n id = {921df3e2-5fca-396b-81ec-a18863f61770},\n created = {2022-08-02T01:01:25.646Z},\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-23T00:59:38.651Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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 Bug Locator. 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 Bug Locator identified only 51.02%. In the Android ZXing project, our approach identified 85.71%, while Bug Locator identified 60%. © 2013 IEEE.},\n bibtype = {inproceedings},\n author = {Chakkrit Tantithamthavorn, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/SNPD.2013.92},\n booktitle = {SNPD 2013 - 14th ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing}\n}
\n
\n\n\n
\n 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 Bug Locator. 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 Bug Locator identified only 51.02%. In the Android ZXing project, our approach identified 85.71%, while Bug Locator identified 60%. © 2013 IEEE.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 不具合修正プロセス効率化に向けた修正者の立場から見た管理者別タスク優先度の比較.\n \n \n \n\n\n \n Hayato Yoshiyuki; Masao Ohira; and Akinori Ihara\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2013.\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 = {2013},\n month = {9},\n id = {8a88de89-ab27-3050-9b2a-9a16963f2a50},\n created = {2022-08-09T01:34:41.209Z},\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-09T01:34:41.209Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hayato Yoshiyuki, undefined and Masao Ohira, undefined and Akinori Ihara, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 学習データの時間的変化に伴う欠陥モジュール予測モデルの評価.\n \n \n \n\n\n \n Satoshi Uchigaki; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2013.\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 = {2013},\n month = {9},\n id = {5ffe3bb0-962b-3a5b-b0fb-d324a0e36a7c},\n created = {2022-08-09T01:34:53.862Z},\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-09T01:34:53.862Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Satoshi Uchigaki, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, 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 Satoshi Uchigaki; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 11 2013.\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 = {2013},\n month = {11},\n id = {1f62854b-6d4e-3817-88b9-6fbc7a33a38a},\n created = {2022-08-09T01:34:55.056Z},\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:54.554Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Satoshi Uchigaki, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Software Project Tomography: a New Concept for Quantitative Project Management and Assessment in Software Development.\n \n \n \n\n\n \n Kenichi Matsumoto; Akito Monden; and Akinori Ihara\n\n\n \n\n\n\n The International Conference on Project Management. 11 2013.\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 = {Software Project Tomography: a New Concept for Quantitative Project Management and Assessment in Software Development},\n type = {article},\n year = {2013},\n month = {11},\n id = {be46314e-7b40-3b35-843d-409dd8ee78ef},\n created = {2022-08-09T01:36:29.489Z},\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-09T01:36:29.489Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kenichi Matsumoto, undefined and Akito Monden, undefined and Akinori Ihara, undefined},\n journal = {The International Conference on Project Management}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発における不具合割当パターンに着目した不具合修正時間の予測.\n \n \n \n\n\n \n Hitoshi Masaki; Masao Ohira; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会論文誌. 2 2013.\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 = {OSS開発における不具合割当パターンに着目した不具合修正時間の予測},\n type = {article},\n year = {2013},\n month = {2},\n id = {91fa21f0-0fbc-306f-8e3d-da4bff2a8be6},\n created = {2022-08-09T01:36:44.323Z},\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-09T01:36:44.323Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hitoshi Masaki, undefined and Masao Ohira, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会論文誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発における協調作業と不具合再修正の分析.\n \n \n \n\n\n \n Hironori Hayashi; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェアエンジニアリングシンポジウム. 9 2013.\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 = {OSS開発における協調作業と不具合再修正の分析},\n type = {article},\n year = {2013},\n month = {9},\n id = {ad7e0a36-b363-30cd-87a2-7ef79d3ca784},\n created = {2022-08-09T01:36:45.523Z},\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-09T01:36:45.523Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hironori Hayashi, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェアエンジニアリングシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆OSS開発におけるレビュアー間の合意形成の分析.\n \n \n \n\n\n \n Hironori Hayashi; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n グループウェアとネットワークサービスワークショップ. 11 2013.\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]🏆OSS開発におけるレビュアー間の合意形成の分析},\n type = {article},\n year = {2013},\n month = {11},\n id = {bca0159f-c3ba-38c3-bc22-67d13d413784},\n created = {2022-08-09T01:36:46.689Z},\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:54:33.615Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hironori Hayashi, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {グループウェアとネットワークサービスワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 OSS開発における一般開発者の協調作業と不具合の再修正に関する一考察.\n \n \n \n\n\n \n Hironori Hayashi; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2013.\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]🏆 OSS開発における一般開発者の協調作業と不具合の再修正に関する一考察},\n type = {article},\n year = {2013},\n month = {7},\n id = {62803779-b0b0-3b23-bf4a-0b0a5e72b5c8},\n created = {2022-08-09T01:37:51.500Z},\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-09T01:37:51.500Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hironori Hayashi, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 「ソフトウェア工学の実証的アプローチ」シリーズ第5回 ソフトウェアリポジトリマイニング.\n \n \n \n\n\n \n Akito Monden; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n JSSST journal. 5 2013.\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 = {「ソフトウェア工学の実証的アプローチ」シリーズ第5回 ソフトウェアリポジトリマイニング},\n type = {article},\n year = {2013},\n month = {5},\n id = {404c6003-5338-397b-ae96-249cf27fbe69},\n created = {2022-08-09T01:37:52.497Z},\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-09T01:37:52.497Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akito Monden, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {JSSST journal}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSプロジェクトにおけるユーザ用メーリングリストの実態調査.\n \n \n \n\n\n \n Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会研究報告. 5 2013.\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 = {OSSプロジェクトにおけるユーザ用メーリングリストの実態調査},\n type = {article},\n year = {2013},\n month = {5},\n id = {bd2c11d5-d2da-39f4-8c76-6d3c9471bb50},\n created = {2022-08-19T02:23:15.483Z},\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-19T02:23:15.483Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会研究報告}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発におけるコミッターの協調作業についての一考察.\n \n \n \n\n\n \n Hironori Hayashi; Akinori Ihara; Akito Monden; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会研究報告. 5 2013.\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 = {OSS開発におけるコミッターの協調作業についての一考察},\n type = {article},\n year = {2013},\n month = {5},\n id = {81c27a5a-4001-3153-a2b4-cc89bd8339f1},\n created = {2022-08-19T02:23:19.292Z},\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-19T02:23:19.292Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hironori Hayashi, undefined and Akinori Ihara, undefined and Akito Monden, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会研究報告}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n クラッシュログを用いたソースコード不具合箇所の特定に向けた分析.\n \n \n \n\n\n \n Takamitsu Nagamoto; Yasutaka Kamei; Akinori Ihara; and Naoyasu Ubayashi\n\n\n \n\n\n\n 電子情報通信学会技術報告. 3 2013.\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 = {2013},\n month = {3},\n id = {4d4c3347-41fc-3fe4-9cb0-b5e6d8171f46},\n created = {2022-08-19T02:24:22.477Z},\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-19T02:24:22.477Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Takamitsu Nagamoto, undefined and Yasutaka Kamei, undefined and Akinori Ihara, undefined and Naoyasu Ubayashi, undefined},\n journal = {電子情報通信学会技術報告}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n リポジトリマイニングの研究成果の産業化への応用.\n \n \n \n\n\n \n Akito Monden; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n JSSST journal. 5 2013.\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 = {2013},\n month = {5},\n id = {bc0a16df-7e25-3a11-a09d-9720f5c0b715},\n created = {2022-08-19T02:25:03.981Z},\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-19T02:25:03.981Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akito Monden, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {JSSST journal}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 形態素N-gramを用いた不具合修正完了ソースコードの特定.\n \n \n \n\n\n \n Hiroki Kawai; Hidetake Uwano; and Akinori Ihara\n\n\n \n\n\n\n 電子情報通信学会技術報告. 3 2013.\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-gramを用いた不具合修正完了ソースコードの特定},\n type = {article},\n year = {2013},\n month = {3},\n id = {b57c9d27-8647-31c0-8f46-6540eee6a17f},\n created = {2022-08-19T02:25:14.160Z},\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-19T02:25:14.160Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Hiroki Kawai, undefined and Hidetake Uwano, undefined and Akinori Ihara, undefined},\n journal = {電子情報通信学会技術報告}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2012\n \n \n (7)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n Locating source code to be fixed based on initial bug reports - A case study on the eclipse project.\n \n \n \n\n\n \n Phiradet Bangcharoensap; Akinori Ihara; Yasutaka Kamei; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - 2012 4th International Workshop on Empirical Software Engineering in Practice, IWESEP 2012, 2012. \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 = {Locating source code to be fixed based on initial bug reports - A case study on the eclipse project},\n type = {inproceedings},\n year = {2012},\n keywords = {Bug localization,Change history mining,Code mining,Text mining},\n id = {3dd7f72b-26d6-3d5b-b116-b9d091d57d44},\n created = {2022-08-02T01:00:40.720Z},\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:46:15.551Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Phiradet Bangcharoensap, undefined and Akinori Ihara, undefined and Yasutaka Kamei, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/IWESEP.2012.14},\n booktitle = {Proceedings - 2012 4th International Workshop on Empirical Software Engineering in Practice, IWESEP 2012}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n An investigation on software bug-fix prediction for open source software projects - A case study on the eclipse project.\n \n \n \n\n\n \n Akinori Ihara; Yasutaka Kamei; Akito Monden; Masao Ohira; Jacky Wai Keung; Naoyasu Ubayashi; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - Asia-Pacific Software Engineering Conference, APSEC, volume 2, 2012. \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
@inproceedings{\n title = {An investigation on software bug-fix prediction for open source software projects - A case study on the eclipse project},\n type = {inproceedings},\n year = {2012},\n keywords = {Bug-Fix Prediction Model,Open Source Software},\n volume = {2},\n id = {ab65cadf-4f93-3c98-b3d5-1998ee1f432d},\n created = {2022-08-02T01:00:53.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-19T05:10:02.941Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Open source software projects (OSS) receive a large number of bug reports from various contributors and developers alike, where many planned to be fixed by OSS developers. Given the next release cycle information, OSS users can be more effective and flexible in planning and to fix the bugs that are not to be fixed in the next release. It is therefore vital for OSS users to learn which bugs the OSS developers will fix, unfortunately such information may not be readily available, nor there is a prediction framework exists to serve such an important purpose. In this study, we would like to answer the question 'Will this bug be fixed by the next release?', this is addressed by building a bug fixing prediction model based on the characteristics of a bug-related metric and by incorporating the progress of bug fixing measures such as status, period and developer metrics to provide aggregated information for the OSS users. The proposed model calculates the deviance of each variable to analyze the most important metrics, and it has been experimented using a case study with Eclipse platform. Result shows a bug fixing prediction model using both base metrics and state metrics provide significantly better performance in precision (139%) and recall (114\\%) than the standard model using only base metrics. © 2012 IEEE.},\n bibtype = {inproceedings},\n author = {Akinori Ihara, undefined and Yasutaka Kamei, undefined and Akito Monden, undefined and Masao Ohira, undefined and Jacky Wai Keung, undefined and Naoyasu Ubayashi, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/APSEC.2012.86},\n booktitle = {Proceedings - Asia-Pacific Software Engineering Conference, APSEC}\n}
\n
\n\n\n
\n Open source software projects (OSS) receive a large number of bug reports from various contributors and developers alike, where many planned to be fixed by OSS developers. Given the next release cycle information, OSS users can be more effective and flexible in planning and to fix the bugs that are not to be fixed in the next release. It is therefore vital for OSS users to learn which bugs the OSS developers will fix, unfortunately such information may not be readily available, nor there is a prediction framework exists to serve such an important purpose. In this study, we would like to answer the question 'Will this bug be fixed by the next release?', this is addressed by building a bug fixing prediction model based on the characteristics of a bug-related metric and by incorporating the progress of bug fixing measures such as status, period and developer metrics to provide aggregated information for the OSS users. The proposed model calculates the deviance of each variable to analyze the most important metrics, and it has been experimented using a case study with Eclipse platform. Result shows a bug fixing prediction model using both base metrics and state metrics provide significantly better performance in precision (139%) and recall (114\\%) than the standard model using only base metrics. © 2012 IEEE.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Good or bad committers? - A case study of committer's activities on the eclipse's bug fixing process.\n \n \n \n\n\n \n Anakorn Jongyindee; Masao Ohira; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n IEICE Transactions on Information and Systems, E95-D(9). 2012.\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 = {Good or bad committers? - A case study of committer's activities on the eclipse's bug fixing process},\n type = {article},\n year = {2012},\n keywords = {Bug fixing process,Committer,Open source software (OSS)},\n volume = {E95-D},\n id = {0beb9170-ee59-3293-808a-2ab4be4b698a},\n created = {2022-08-02T01:01:00.619Z},\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:31:32.346Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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 a software repository, plays a major role in this process and holds a key to the successfulness of the project. Despite the importance of committer's activities, we suspect that sometimes committers can make mistakes which have some consequences to the bug fixing process (e.g., reopened bugs after bug fixing). Our research focuses on studying the consequences of each committer's activities to this process. We collected each committer's historical data from the Eclipse- Platform's bug tracking system and version control system and evaluated their activities using bug status in the bug tracking system and commit log in the version control system. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. Copyright © 2012 The Institute of Electronics, Information and Communication Engineers.},\n bibtype = {article},\n author = {Anakorn Jongyindee, undefined and Masao Ohira, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1587/transinf.E95.D.2202},\n journal = {IEICE Transactions on Information and Systems},\n number = {9}\n}
\n
\n\n\n
\n 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 a software repository, plays a major role in this process and holds a key to the successfulness of the project. Despite the importance of committer's activities, we suspect that sometimes committers can make mistakes which have some consequences to the bug fixing process (e.g., reopened bugs after bug fixing). Our research focuses on studying the consequences of each committer's activities to this process. We collected each committer's historical data from the Eclipse- Platform's bug tracking system and version control system and evaluated their activities using bug status in the bug tracking system and commit log in the version control system. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. Copyright © 2012 The Institute of Electronics, Information and Communication Engineers.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n An algorithm for gradual patch acceptance detection in Open Source software repository mining.\n \n \n \n\n\n \n Passakorn Phannachitta; Akinori Ihara; Pijak Jirapiwong; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, E95-A(9). 2012.\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\n
\n
@article{\n title = {An algorithm for gradual patch acceptance detection in Open Source software repository mining},\n type = {article},\n year = {2012},\n keywords = {Open Source Software,Oss evolution pattern,Oss repository mining,Patch acceptance,Patch submission},\n volume = {E95-A},\n id = {841cde3f-319e-311e-9623-e793f379cd40},\n created = {2022-08-02T01:01:13.868Z},\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-19T04:47:46.213Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {Nowadays, software development societies have given more precedence to Open Source Software (OSS). There is much research aimed at understanding the OSS society to sustain the OSS product. To lead an OSS project to a successful conclusion, researchers study how developers change source codes called patches in project repositories. In existing studies, we found an argument in the conventional patch acceptance detection procedure. It was so simplified that it omitted important cases from the analysis, and would lead researchers to wrong conclusions. In this research, we propose an algorithm to overcome the problem. To prove out our algorithm, we constructed a framework and conducted two case studies. As a result, we came to a new and interesting understanding of patch activities. Copyright © 2012 The Institute of Electronics.},\n bibtype = {article},\n author = {Passakorn Phannachitta, undefined and Akinori Ihara, undefined and Pijak Jirapiwong, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1587/transfun.E95.A.1478},\n journal = {IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences},\n number = {9}\n}
\n
\n\n\n
\n Nowadays, software development societies have given more precedence to Open Source Software (OSS). There is much research aimed at understanding the OSS society to sustain the OSS product. To lead an OSS project to a successful conclusion, researchers study how developers change source codes called patches in project repositories. In existing studies, we found an argument in the conventional patch acceptance detection procedure. It was so simplified that it omitted important cases from the analysis, and would lead researchers to wrong conclusions. In this research, we propose an algorithm to overcome the problem. To prove out our algorithm, we constructed a framework and conducted two case studies. As a result, we came to a new and interesting understanding of patch activities. Copyright © 2012 The Institute of Electronics.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 奈良先端科学技術大学院大学 最優秀学生賞.\n \n \n \n\n\n \n Akinori Ihara\n\n\n \n\n\n\n NAIST. 3 2012.\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 = {2012},\n month = {3},\n id = {fb6d2f8e-a17c-35fd-bbf6-482fd9c8dd43},\n created = {2022-08-19T02:22:11.815Z},\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-19T02:22:11.815Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined},\n journal = {NAIST}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSプロジェクトにおける開発者の活動量を用いたコミッター候補者予測.\n \n \n \n\n\n \n Akinori Ihara; Yasutaka Kamei; Masao Ohira; Kenichi Matsumoto; and Naoyasu Ubayash\n\n\n \n\n\n\n 電子情報通信学会論文誌. 2 2012.\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 = {OSSプロジェクトにおける開発者の活動量を用いたコミッター候補者予測},\n type = {article},\n year = {2012},\n month = {2},\n id = {cb28e5fd-78a7-359f-886e-5aab8bbc23d7},\n created = {2022-08-19T02:23:16.432Z},\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-19T02:23:16.432Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Yasutaka Kamei, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined and Naoyasu Ubayash, undefined},\n journal = {電子情報通信学会論文誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 情報検索手法を用いた開発支援システム間の情報統合.\n \n \n \n\n\n \n Soichiro Tani; Hidetake Uwano; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア工学の基礎ワークショップ. 12 2012.\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 = {2012},\n month = {12},\n id = {97aeb3b0-6309-383c-93c6-33420a67abd8},\n created = {2022-08-19T02:25:20.186Z},\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-19T02:25:20.186Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Soichiro Tani, undefined and Hidetake Uwano, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2011\n \n \n (7)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n An analysis of gradual patch application: A better explanation of patch acceptance.\n \n \n \n\n\n \n Passakorn Phannachitta; Pijak Jirapiwong; Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n In 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, 2011. \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
@inproceedings{\n title = {An analysis of gradual patch application: A better explanation of patch acceptance},\n type = {inproceedings},\n year = {2011},\n id = {58c29806-662f-3b43-af51-da2b875794ff},\n created = {2022-08-02T01:01:14.834Z},\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-19T04:50:24.728Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Passakorn Phannachitta, undefined and Pijak Jirapiwong, undefined and Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/IWSM-MENSURA.2011.36},\n booktitle = {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}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n A Case Study of the Consequences from Committers’ Activities on the Bug Fixing Process in the Eclipse Project.\n \n \n \n\n\n \n Anakorn Jongyindee; Masao Ohira; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 11 2011.\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 = {A Case Study of the Consequences from Committers’ Activities on the Bug Fixing Process in the Eclipse Project},\n type = {article},\n year = {2011},\n month = {11},\n id = {b6354498-d2fa-3250-9d79-4766c2e25881},\n created = {2022-08-19T02:22:14.680Z},\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-19T02:22:14.680Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Anakorn Jongyindee, undefined and Masao Ohira, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, 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 A System for Information Integration between Development Support Systems.\n \n \n \n\n\n \n Soichiro Tani; Akinori Ihara; Masao Ohira; Hidetake Uwano; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Software Measurement and the International Conference on Software Process and Product Measurement. 11 2011.\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 = {A System for Information Integration between Development Support Systems},\n type = {article},\n year = {2011},\n month = {11},\n id = {f243b62c-1fd3-3341-9308-44ac425f626b},\n created = {2022-08-19T02:22:17.683Z},\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-19T02:22:17.683Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Soichiro Tani, undefined and Akinori Ihara, undefined and Masao Ohira, undefined and Hidetake Uwano, undefined and Kenichi Matsumoto, undefined},\n journal = {International Workshop on Software Measurement and the International Conference on Software Process and Product Measurement}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発におけるコミッター選出のための開発者の活動量に関する実証的分析.\n \n \n \n\n\n \n Akinori Ihara; Shoji Fujita; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n 第18回ソフトウェア工学の基礎ワークショップ. 11 2011.\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 = {OSS開発におけるコミッター選出のための開発者の活動量に関する実証的分析},\n type = {article},\n year = {2011},\n month = {11},\n id = {18bfb19d-318b-39b8-be4b-21fb1bc57ff9},\n created = {2022-08-19T02:23:20.228Z},\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-19T02:23:20.228Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Shoji Fujita, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {第18回ソフトウェア工学の基礎ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発における不具合修正プロセスの現状と課題 :不具合修正時間の短縮化へ向けた分析.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報社会学会誌. 11 2011.\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 = {OSS開発における不具合修正プロセスの現状と課題 :不具合修正時間の短縮化へ向けた分析},\n type = {article},\n year = {2011},\n month = {11},\n id = {05719a91-9584-3676-9e93-feb13dbe93f9},\n created = {2022-08-19T02:23:28.404Z},\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-19T02:23:28.404Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {情報社会学会誌}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Understanding OSS Openness Through Relationship between Patch Acceptance and Evolution Pattern.\n \n \n \n\n\n \n Passakorn Phannachitta; Pijak Jirapiwong; Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 11 2011.\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 = {Understanding OSS Openness Through Relationship between Patch Acceptance and Evolution Pattern},\n type = {article},\n year = {2011},\n month = {11},\n id = {9c7427a7-39d8-32e8-a648-3bb3e2311ad1},\n created = {2022-08-19T02:24:01.607Z},\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-19T02:24:01.607Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Passakorn Phannachitta, undefined and Pijak Jirapiwong, undefined and Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, 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 グローバル環境下におけるOSS開発者の情報交換に対する時差の影響.\n \n \n \n\n\n \n Yasutaka Kamei; Masao Ohira; Akinori Ihara; Kiwako Koyama; Shinsuke Matsumoto; Kenichi Matsumoto; and Naoyasu Ubayashi\n\n\n \n\n\n\n 情報社会学会誌. 11 2011.\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 = {グローバル環境下におけるOSS開発者の情報交換に対する時差の影響},\n type = {article},\n year = {2011},\n month = {11},\n id = {7cae2ed1-93f7-34c0-8ea8-bb6b2f7c2cb0},\n created = {2022-08-19T02:24:23.486Z},\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-19T02:24:23.486Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Yasutaka Kamei, undefined and Masao Ohira, undefined and Akinori Ihara, undefined and Kiwako Koyama, undefined and Shinsuke Matsumoto, undefined and Kenichi Matsumoto, undefined and Naoyasu Ubayashi, undefined},\n journal = {情報社会学会誌}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2010\n \n \n (5)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n A time-lag analysis for improving communication among OSS developers.\n \n \n \n\n\n \n Masao Ohira; Kiwako Koyama; Akinori Ihara; Shinsuke Matsumoto; Yasutaka Kamei; and Kenichi Matsumoto\n\n\n \n\n\n\n Volume 6284 LNAI 2010.\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 = {A time-lag analysis for improving communication among OSS developers},\n type = {book},\n year = {2010},\n source = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},\n keywords = {OSS,distributed development,time-lag analysis},\n volume = {6284 LNAI},\n id = {13b92f66-9618-3d59-988d-1d770e7a0b09},\n created = {2022-08-02T01:01:12.993Z},\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-19T04:44:58.462Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {In the open source software (OSS) development environment, a communication time-lag among developers is more likely to happen due to time differences among locations of developers and differences of working hours for OSS development. A means for effective communication among OSS developers has been increasingly demanded in recent years, since an OSS product and its users requires a prompt response to issues such as defects and security vulnerabilities. In this paper, we propose an analysis method for observing the time-lag of communication among developers in an OSS project and then facilitating the communication. © 2010 Springer-Verlag.},\n bibtype = {book},\n author = {Masao Ohira, undefined and Kiwako Koyama, undefined and Akinori Ihara, undefined and Shinsuke Matsumoto, undefined and Yasutaka Kamei, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1007/978-3-642-14888-0_13}\n}
\n
\n\n\n
\n In the open source software (OSS) development environment, a communication time-lag among developers is more likely to happen due to time differences among locations of developers and differences of working hours for OSS development. A means for effective communication among OSS developers has been increasingly demanded in recent years, since an OSS product and its users requires a prompt response to issues such as defects and security vulnerabilities. In this paper, we propose an analysis method for observing the time-lag of communication among developers in an OSS project and then facilitating the communication. © 2010 Springer-Verlag.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n Predicting re-opened bugs: A case study on the Eclipse project.\n \n \n \n\n\n \n Emad Shihab; Akinori Ihara; Yasutaka Kamei; Walid M. Ibrahim; Masao Ohira; Bram Adams; Ahmed E. Hassan; and Kenichi Matsumoto\n\n\n \n\n\n\n In Proceedings - Working Conference on Reverse Engineering, WCRE, 2010. \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
@inproceedings{\n title = {Predicting re-opened bugs: A case study on the Eclipse project},\n type = {inproceedings},\n year = {2010},\n id = {47557ef1-0175-3dbc-bbf6-6448c6aaf0e3},\n created = {2022-08-02T01:01:19.075Z},\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:07:16.846Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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.},\n bibtype = {inproceedings},\n author = {Emad Shihab, undefined and Akinori Ihara, undefined and Yasutaka Kamei, undefined and Walid M. Ibrahim, undefined and Masao Ohira, undefined and Bram Adams, undefined and Ahmed E. Hassan, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1109/WCRE.2010.36},\n booktitle = {Proceedings - Working Conference on Reverse Engineering, WCRE}\n}
\n
\n\n\n
\n 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.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 OSS開発におけるパッチレビュープロセスの効率化に向けたコミッターの分類.\n \n \n \n\n\n \n Shoji Fujita; Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n 平成22年度 情報処理学会関西支部支部大会. 9 2010.\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]🏆 OSS開発におけるパッチレビュープロセスの効率化に向けたコミッターの分類},\n type = {article},\n year = {2010},\n month = {9},\n id = {016854e5-cbb1-37a6-8d07-dd90b2629c6e},\n created = {2022-08-19T02:22:08.889Z},\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-19T02:22:08.889Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Shoji Fujita, undefined and Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {平成22年度 情報処理学会関西支部支部大会}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 OSS開発における保守対応の効率化のためのアウェアネス支援システム.\n \n \n \n\n\n \n Akinori Ihara; Mizuki Yamamoto; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2010.\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]🏆 OSS開発における保守対応の効率化のためのアウェアネス支援システム},\n type = {article},\n year = {2010},\n month = {7},\n id = {11e8479a-4cb2-3aa2-b9b7-6a0e9bc8e01c},\n created = {2022-08-19T02:22:10.788Z},\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-19T02:22:10.788Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Mizuki Yamamoto, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n An Analysis of Committers Toward Improving the Patch Review Process in Oss Development.\n \n \n \n\n\n \n Shoji Fujita; Masao Ohira; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n The 27th International Symposium on Software Reliability Engineering. 11 2010.\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 Committers Toward Improving the Patch Review Process in Oss Development},\n type = {article},\n year = {2010},\n month = {11},\n id = {cac03f54-b8e9-3756-8f3d-4018bbb36e83},\n created = {2022-08-19T02:22:25.952Z},\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-19T02:22:25.952Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Shoji Fujita, undefined and Masao Ohira, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {The 27th International Symposium on Software Reliability Engineering}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2009\n \n \n (9)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n An analysis method for improving a bug modification process in open source software development.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n In International Workshop on Principles of Software Evolution (IWPSE), 2009. \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\n\n\n
\n
@inproceedings{\n title = {An analysis method for improving a bug modification process in open source software development},\n type = {inproceedings},\n year = {2009},\n keywords = {Apache,Bug tracking system,Firefox,Modification process,Open source software development,Repository mining},\n id = {0f9e5f62-8d99-3c3e-970d-22d14e86834b},\n created = {2022-08-02T01:00:54.640Z},\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-19T04:45:57.803Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {true},\n abstract = {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, the 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. Copyright 2009 ACM.},\n bibtype = {inproceedings},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n doi = {10.1145/1595808.1595833},\n booktitle = {International Workshop on Principles of Software Evolution (IWPSE)}\n}
\n
\n\n\n
\n 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, the 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. Copyright 2009 ACM.\n
\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 不具合管理システム利用時の不具合修正プロセス改善のための滞留時間分析手法の提案.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2009.\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 = {2009},\n month = {7},\n id = {b3685602-9dd3-3680-b750-26b631848416},\n created = {2022-08-19T02:22:12.819Z},\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-19T02:22:12.819Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n A Time-Lag Analysis Toward Improving the Efficiency of Communications among OSS Developers.\n \n \n \n\n\n \n Masao Ohira; Kiwako Koyama; Akinori Ihara; Shinsuke Matsumoto; Yasutaka Kamei; and Kenichi Matsumoto\n\n\n \n\n\n\n The 3rd International Workshop on Knowledge Collaboration in Software Development. 11 2009.\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 = {A Time-Lag Analysis Toward Improving the Efficiency of Communications among OSS Developers},\n type = {article},\n year = {2009},\n month = {11},\n id = {07a11d86-c3b0-3515-87c2-45aae90666d7},\n created = {2022-08-19T02:22:20.928Z},\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-19T02:22:20.928Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Masao Ohira, undefined and Kiwako Koyama, undefined and Akinori Ihara, undefined and Shinsuke Matsumoto, undefined and Yasutaka Kamei, undefined and Kenichi Matsumoto, undefined},\n journal = {The 3rd International Workshop on Knowledge Collaboration in Software Development}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n A Visualization System for Analyzing Large-Scale Complex Data.\n \n \n \n\n\n \n Akinori Ihara\n\n\n \n\n\n\n International Workshop on Empirical Software Engineering in Practice. 10 2009.\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 = {A Visualization System for Analyzing Large-Scale Complex Data},\n type = {article},\n year = {2009},\n month = {10},\n id = {40828aa1-07fd-326e-9377-ea1fc6811134},\n created = {2022-08-19T02:22:21.904Z},\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-19T02:22:21.904Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {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 Differences of Time between Modification and Re-Modification: an Analysis of a Bug Tracking System.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n The 3rd International Workshop on Knowledge Collaboration in Software Development. 11 2009.\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 = {Differences of Time between Modification and Re-Modification: an Analysis of a Bug Tracking System},\n type = {article},\n year = {2009},\n month = {11},\n id = {a3cfc364-ff52-34dc-8309-200f0f086b35},\n created = {2022-08-19T02:22:38.954Z},\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-19T02:22:38.954Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {The 3rd International Workshop on Knowledge Collaboration in Software Development}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSの開発状況理解支援のための可視化手法の提案.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; Shinsuke Matsumoto; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会 グループウェアとネットワークサービス・ワークショップ. 9 2009.\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 = {OSSの開発状況理解支援のための可視化手法の提案},\n type = {article},\n year = {2009},\n month = {9},\n id = {aa9108a3-b0c3-351a-b54b-58e83f7c6bb5},\n created = {2022-08-19T02:23:11.635Z},\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-19T02:23:11.635Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Shinsuke Matsumoto, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会 グループウェアとネットワークサービス・ワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSSの障害修正における開発者ネットワークの分析.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; Kiwako Koyama; and Kenichi Matsumoto\n\n\n \n\n\n\n 第5回ネットワーク生態学シンポジウム. 3 2009.\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 = {OSSの障害修正における開発者ネットワークの分析},\n type = {article},\n year = {2009},\n month = {3},\n id = {f866907c-2e74-3391-9ca0-c1a24a5c42f9},\n created = {2022-08-19T02:23:12.700Z},\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-19T02:23:12.700Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Kiwako Koyama, undefined and Kenichi Matsumoto, undefined},\n journal = {第5回ネットワーク生態学シンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n OSS開発における情報交換の効率改善へ向けたタイムラグ分析手法の提案.\n \n \n \n\n\n \n Kiwako Koyama; Akinori Ihara; Shinsuke Matsumoto; Yasutaka Kamei; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会 グループウェアとネットワークサービスワークショップ. 9 2009.\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 = {OSS開発における情報交換の効率改善へ向けたタイムラグ分析手法の提案},\n type = {article},\n year = {2009},\n month = {9},\n id = {97f49fc9-1285-3a2c-9bcd-be9140e12be3},\n created = {2022-08-19T02:23:26.362Z},\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-19T02:23:26.362Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Kiwako Koyama, undefined and Akinori Ihara, undefined and Shinsuke Matsumoto, undefined and Yasutaka Kamei, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会 グループウェアとネットワークサービスワークショップ}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 障害管理システム利用時の修正遅延要因の分析.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n ソフトウェア信頼性研究会. 3 2009.\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 = {2009},\n month = {3},\n id = {43447dcb-85ee-389d-a777-2de10f60f210},\n created = {2022-08-19T02:25:18.287Z},\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-19T02:25:18.287Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {ソフトウェア信頼性研究会}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2008\n \n \n (3)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 OSSプロジェクトにおける障害に関する情報共有の分析.\n \n \n \n\n\n \n Akinori Ihara; Yasutaka Kamei; Masao Ohira; Shinsuke Matsumoto; and Kenichi Matsumoto\n\n\n \n\n\n\n 平成20年度 情報処理学会関西支部支部大会. 10 2008.\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]🏆 OSSプロジェクトにおける障害に関する情報共有の分析},\n type = {article},\n year = {2008},\n month = {10},\n id = {7907a7ea-a652-32cf-8fb1-cf9e63060790},\n created = {2022-08-19T02:22:05.321Z},\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-19T02:22:05.321Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Yasutaka Kamei, undefined and Masao Ohira, undefined and Shinsuke Matsumoto, undefined and Kenichi Matsumoto, undefined},\n journal = {平成20年度 情報処理学会関西支部支部大会}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n 🏆[Award]🏆 複数のサブコミュニティを有するOSSコミュニティを対象としたネットワーク分析.\n \n \n \n\n\n \n Akinori Ihara; Masao Ohira; Shinsuke Matsumoto; Yasutaka Kamei; and Kenichi Matsumoto\n\n\n \n\n\n\n マルチメディア,分散,協調とモバイルシンポジウム. 7 2008.\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]🏆 複数のサブコミュニティを有するOSSコミュニティを対象としたネットワーク分析},\n type = {article},\n year = {2008},\n month = {7},\n id = {af5149b6-c720-366f-89e3-106c63a916fd},\n created = {2022-08-19T02:22:13.773Z},\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-19T02:22:13.773Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Masao Ohira, undefined and Shinsuke Matsumoto, undefined and Yasutaka Kamei, undefined and Kenichi Matsumoto, undefined},\n journal = {マルチメディア,分散,協調とモバイルシンポジウム}\n}
\n
\n\n\n\n
\n\n\n
\n \n\n \n \n \n \n \n オープンメディアを活用した知識コミュニティのデザインに関する一考察.\n \n \n \n\n\n \n Masao Ohira; Shinsuke Matsumoto; Akinori Ihara; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報社会学会 「知識共有コミュニティワークショップ ―インターネット上の知識検索サービス研究―」. 11 2008.\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 = {2008},\n month = {11},\n id = {bb582e36-c7d6-3866-bd39-dbb846416571},\n created = {2022-08-19T02:24:19.581Z},\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-19T02:24:19.581Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Masao Ohira, undefined and Shinsuke Matsumoto, undefined and Akinori Ihara, undefined and Kenichi Matsumoto, undefined},\n journal = {情報社会学会 「知識共有コミュニティワークショップ ―インターネット上の知識検索サービス研究―」}\n}
\n
\n\n\n\n
\n\n\n\n\n\n
\n
\n\n
\n
\n  \n 2007\n \n \n (1)\n \n \n
\n
\n \n \n
\n \n\n \n \n \n \n \n 複数のサブコミュニティを有するOSSコミュニティにおけるコーディネータの分析.\n \n \n \n\n\n \n Akinori Ihara; Hirotaka Maeshima; Shinsuke Matsumoto; Yasutaka Kamei; Masao Ohira; and Kenichi Matsumoto\n\n\n \n\n\n\n 情報処理学会 グループウェアとネットワークサービス・ワークショップ. 11 2007.\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 = {複数のサブコミュニティを有するOSSコミュニティにおけるコーディネータの分析},\n type = {article},\n year = {2007},\n month = {11},\n id = {7485187f-58a3-3e74-9987-07c672e56317},\n created = {2022-08-19T02:25:26.182Z},\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-19T02:25:26.182Z},\n read = {false},\n starred = {false},\n authored = {false},\n confirmed = {false},\n hidden = {false},\n private_publication = {false},\n bibtype = {article},\n author = {Akinori Ihara, undefined and Hirotaka Maeshima, undefined and Shinsuke Matsumoto, undefined and Yasutaka Kamei, undefined and Masao Ohira, undefined and Kenichi Matsumoto, undefined},\n journal = {情報処理学会 グループウェアとネットワークサービス・ワークショップ}\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
\n"}; document.write(bibbase_data.data);