starlee
/
pr_survey
0
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

add tex files

This commit is contained in:
whystar 2020-08-31 09:12:57 +08:00
parent 5aa9275215
commit f6931ce02d
31 changed files with 11338 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -1 +1,2 @@
~$*
~$*
*.gz

4
1-introduction.tex Normal file
View File

@ -0,0 +1,4 @@
\section{Introduction}
***~\cite{Gousios:2014}

89
2-slr-procedure.tex Normal file
View File

@ -0,0 +1,89 @@
\section{Systematic Review Procedure}
\subsection{Question formulation}
The following three research questions:
\textbf{RQ1: What is trend in the study of GitHub pull requests?}
\textbf{RQ2: What topics have been studied in relation to GitHub pull requests?}
\textbf{RQ3: What metrics have been used to study GitHub pull requests?}
\subsection{Literature search}
\subsubsection{Search sources}
\begin{itemize}
\item IEEE Xplore
\item ACM Digital Library
\item dblp
\item Springer Link
\item Google Scholar
\item arXive
\end{itemize}
\subsubsection{Search strings}
\texttt{\textit{(pull request) or (pull based development) or (fork based development)}}
\subsubsection{Search results}
publication year: 2010-2020
\begin{table}[h]
\centering
\caption{Literature search results}
\begin{tabular}{l c}
\toprule
\textbf{Source} & \textbf{Found} \\ \midrule
IEEE Xplore & 209\\
ACM Digital Library & 266\\
dblp & 79\\
Springer Link & 203\\
Google Scholar & 123\\
arXive & 69\\ \midrule
Total (remove duplicates) & 769 \\
\bottomrule
\end{tabular}
\label{tab:search_result}
\end{table}
\subsection{Study selection}
\subsubsection{Inclusion/Exclusion criteria}
\subsubsection{Selectin process}
two stages:
\textbf{Title nad Abstract screening.} ***
\textbf{Full paper screening.} ****
\subsection{Data extraction}
\begin{table}[h]
\centering
\caption{Data extraction}
\begin{tabular}{p{4cm} p{4cm}}
\toprule
\textbf{Research question} & \textbf{Data} \\ \midrule
RQ1: Research Trend & Publication date, venue\\
RQ2: Research Topic & \\
RQ3: Studied Metrics & \\
\bottomrule
\end{tabular}
\label{tab:search_result}
\end{table}

6347
IEEEtran.cls Normal file
View File

File diff suppressed because it is too large Load Diff

0
parse_arxiv.py → experiment/parse_arxiv.py
View File

0
parse_springler.py → experiment/parse_springler.py
View File

0
study-search/acm (1).bib → experiment/study-search/acm (1).bib
View File

0
study-search/acm (2).bib → experiment/study-search/acm (2).bib
View File

0
study-search/acm (3).bib → experiment/study-search/acm (3).bib
View File

0
study-search/acm (4).bib → experiment/study-search/acm (4).bib
View File

0
study-search/acm (5).bib → experiment/study-search/acm (5).bib
View File

0
study-search/arxic.txt → experiment/study-search/arxic.txt
View File

0
study-search/arxiv.bib → experiment/study-search/arxiv.bib
View File

0
study-search/dblp-1.bib → experiment/study-search/dblp-1.bib
View File

0
study-search/dblp-2.bib → experiment/study-search/dblp-2.bib
View File

0
study-search/dblp-3.bib → experiment/study-search/dblp-3.bib
View File

1139
experiment/study-search/gs-1.bib Normal file
View File

File diff suppressed because it is too large Load Diff

671
experiment/study-search/gs-2.bib Normal file
View File

@ -0,0 +1,671 @@
D:\Anaconda3\python.exe D:/Users/小雪/Desktop/dfjskd/sdf.py
@inproceedings{gousios2015work,
abstract = {In the pull-based development model, the integrator has the crucial role of managing and integrating contributions. This work focuses on the role of the integrator and investigates working habits and challenges alike. We set up an exploratory qualitative study involving a},
author = {Gousios, Georgios and Zaidman, Andy and Storey, Margaret-Anne and Van Deursen, Arie},
booktitle = {2015 IEEE/ACM 37th IEEE International Conference on Software Engineering},
cites = {220},
eprint = {https://core.ac.uk/download/pdf/193274956.pdf},
gsrank = {1},
organization = {IEEE},
pages = {358--368},
title = {Work practices and challenges in pull-based development: the integrator's perspective},
url = {https://ieeexplore.ieee.org/abstract/document/7194588/},
venue = {2015 IEEE/ACM 37th …},
volume = {1},
year = {2015}
}
@inproceedings{gousios2016work,
abstract = {The pull-based development model is an emerging way of contributing to distributed software projects that is gaining enormous popularity within the open source software (OSS) world. Previous work has examined this model by focusing on projects and their owners-we},
author = {Gousios, Georgios and Storey, Margaret-Anne and Bacchelli, Alberto},
booktitle = {2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE)},
cites = {149},
eprint = {https://www.zora.uzh.ch/id/eprint/152988/1/pullreqs-contributors.pdf},
gsrank = {2},
organization = {IEEE},
pages = {285--296},
title = {Work practices and challenges in pull-based development: the contributor's perspective},
url = {https://ieeexplore.ieee.org/abstract/document/7886911/},
venue = {2016 IEEE/ACM 38th …},
year = {2016}
}
@inproceedings{gousios2014dataset,
abstract = {Pull requests form a new method for collaborating in distributed software development. To study the pull request distributed development model, we constructed a dataset of almost 900 projects and 350,000 pull requests, including some of the largest users of pull requests},
author = {Gousios, Georgios and Zaidman, Andy},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
cites = {45},
gsrank = {3},
pages = {368--371},
title = {A dataset for pull-based development research},
url = {https://dl.acm.org/doi/abs/10.1145/2597073.2597122},
venue = {Proceedings of the 11th Working Conference …},
year = {2014}
}
@inproceedings{gousios2014exploratory,
abstract = {The advent of distributed version control systems has led to the development of a new paradigm for distributed software development; instead of pushing changes to a central repository, developers pull them from other repositories and merge them locally. Various},
author = {Gousios, Georgios and Pinzger, Martin and Deursen, Arie van},
booktitle = {Proceedings of the 36th International Conference on Software Engineering},
cites = {373},
eprint = {https://www.aau.at/wp-content/uploads/2019/11/Gousios2014-pullbasedmodel.pdf},
gsrank = {4},
pages = {345--355},
title = {An exploratory study of the pull-based software development model},
url = {https://dl.acm.org/doi/abs/10.1145/2568225.2568260},
venue = {Proceedings of the 36th International …},
year = {2014}
}
@article{jiang2017should,
abstract = {Context: The pull-based software development helps developers make contributions flexibly and efficiently. Commenters freely discuss code changes and provide suggestions. Core members make decision of pull requests. Both commenters and core members are},
author = {Jiang, Jing and Yang, Yun and He, Jiahuan and Blanc, Xavier and Zhang, Li},
cites = {31},
gsrank = {5},
journal = {Information and Software Technology},
pages = {48--62},
publisher = {Elsevier},
title = {Who should comment on this pull request? analyzing attributes for more accurate commenter recommendation in pull-based development},
url = {https://www.sciencedirect.com/science/article/pii/S095058491630283X},
venue = {Information and Software …},
volume = {84},
year = {2017}
}
@article{yu2016determinants,
abstract = {The pull-based development model, widely used in distributed software teams on open source communities, can efficiently gather the wisdom from crowds. Instead of sharing access to a central repository, contributors create a fork, update it locally, and request to},
author = {Yu, Yue and Yin, Gang and Wang, Tao and Yang, Cheng and Wang, Huaimin},
cites = {26},
gsrank = {6},
journal = {Science China Information Sciences},
number = {8},
pages = {080104},
publisher = {Springer},
title = {Determinants of pull-based development in the context of continuous integration},
url = {https://link.springer.com/article/10.1007/s11432-016-5595-8},
venue = {Science China Information …},
volume = {59},
year = {2016}
}
@inproceedings{saito2016github,
abstract = {Modern OSS projects have adopted Git to manage versions of their source code and GitHub for hosting their Git repositories. GitHub provides a characteristic feature notably pull request, and many projects adopt pull-based development model by using it. This},
author = {Saito, Yusuke and Fujiwara, Kenji and Igaki, Hiroshi and Yoshida, Norihiro and Iida, Hajimu},
booktitle = {2016 7th International Workshop on Empirical Software Engineering in Practice (IWESEP)},
cites = {11},
gsrank = {7},
organization = {IEEE},
pages = {7--11},
title = {How do github users feel with pull-based development?},
url = {https://ieeexplore.ieee.org/abstract/document/7464545/},
venue = {2016 7th International …},
year = {2016}
}
@article{yang2018revrec,
abstract = {Code review is an important process to reduce code defects and improve software quality. In social coding communities like GitHub, as everyone can submit Pull-Requests, code review plays a more important role than ever before, and the process is quite time-consuming},
author = {Yang, Cheng and Zhang, Xun-hui and Zeng, Ling-bin and Fan, Qiang and Wang, Tao and Yu, Yue and Yin, Gang and Wang, Huai-min},
cites = {8},
eprint = {https://www.researchgate.net/profile/Yue_Yu21/publication/325220923_RevRec_A_two-layer_reviewer_recommendation_algorithm_in_pull-based_development_model/links/5b4c150845851519b4c026fc/RevRec-A-two-layer-reviewer-recommendation-algorithm-in-pull-based-development-model.pdf},
gsrank = {8},
journal = {Journal of Central South University},
number = {5},
pages = {1129--1143},
publisher = {Springer},
title = {RevRec: A two-layer reviewer recommendation algorithm in pull-based development model},
url = {https://link.springer.com/article/10.1007/s11771-018-3812-x},
venue = {Journal of Central South …},
volume = {25},
year = {2018}
}
@inproceedings{yang2017empirical,
abstract = {Code review is an important process to reduce code defects and improve software quality. However, in social coding communities using the pull-based model, everyone can submit code changes, which increases the required code review efforts. Therefore, there is a great},
author = {Yang, Cheng and Zhang, Xunhui and Zeng, Lingbin and Fan, Qiang and Yin, Gang and Wang, Huaimin},
booktitle = {Proceedings of the 9th Asia-Pacific Symposium on Internetware},
cites = {3},
gsrank = {9},
pages = {1--6},
title = {An empirical study of reviewer recommendation in pull-based development model},
url = {https://dl.acm.org/doi/abs/10.1145/3131704.3131718},
venue = {Proceedings of the 9th …},
year = {2017}
}
@inproceedings{li2017automatic,
abstract = {The pull-based model, widely used in distributed software development, allows any contributor to fork a public repository, package contributions as a pull-request, and then merge back to the original repository. Code review is one of the most significant stages in},
author = {Li, Zhixing and Yu, Yue and Yin, Gang and Wang, Tao and Fan, Qiang and Wang, Huaimin},
booktitle = {SEKE},
cites = {3},
eprint = {https://whystar.github.io/res/paper/seke2017.pdf},
gsrank = {10},
pages = {572--577},
title = {Automatic Classification of Review Comments in Pull-based Development Model.},
url = {https://whystar.github.io/res/paper/seke2017.pdf},
venue = {SEKE},
year = {2017}
}
@inproceedings{lu2017using,
abstract = {The pull-based development model is an emerging way of contributing to distributed software projects within the Open Source Software (OSS) communities. To train students' development skills with this modern paradigm and evaluate the effects in classroom settings},
author = {Lu, Yao and Mao, Xinjun and Yin, Gang and Wang, Tao and Bai, Yu},
booktitle = {International Conference on Database Systems for Advanced Applications},
cites = {3},
eprint = {https://www.researchgate.net/profile/Yao_Lu72/publication/315468860_Using_Pull-Based_Collaborative_Development_Model_in_Software_Engineering_Courses_A_Case_Study/links/5cd42e4292851c4eab8df465/Using-Pull-Based-Collaborative-Development-Model-in-Software-Engineering-Courses-A-Case-Study.pdf},
gsrank = {11},
organization = {Springer},
pages = {399--410},
title = {Using Pull-Based Collaborative Development Model in Software Engineering Courses: A Case Study},
url = {https://link.springer.com/chapter/10.1007/978-3-319-55705-2_32},
venue = {International Conference on Database …},
year = {2017}
}
@article{li2017they,
abstract = {Code reviews in pull-based model are open to community users on GitHub. Various participants are taking part in the review discussions and the review topics are not only about the improvement of code contributions but also about project evolution and social},
author = {Li, Zhi-Xing and Yu, Yue and Yin, Gang and Wang, Tao and Wang, Huai-Min},
cites = {3},
eprint = {https://whystar.github.io/res/paper/jcst2017.pdf},
gsrank = {12},
journal = {Journal of Computer Science and Technology},
number = {6},
pages = {1060--1075},
publisher = {Springer},
title = {What Are They Talking About? Analyzing Code Reviews in Pull-Based Development Model},
url = {https://link.springer.com/article/10.1007/s11390-017-1783-2},
venue = {Journal of Computer Science and …},
volume = {32},
year = {2017}
}
@article{wakode2008development,
abstract = {An oral push-pull system that can deliver pramipexole for extended period of time has been developed and characterized. A bilayer osmotic drug delivery system was developed using a basic design consisting of an oral controlled porosity osmotic pump. Unlike other osmotic},
author = {Wakode, Rajeshri and Bhanushali, Roopali and Bajaj, Amrita},
cites = {19},
gsrank = {13},
journal = {PDA journal of pharmaceutical science and technology},
number = {1},
pages = {22--31},
publisher = {Parenteral Drug Association (PDA)},
title = {Development and evaluation of push--pull based osmotic delivery system for pramipexole},
url = {https://journal.pda.org/content/62/1/22.short},
venue = {PDA journal of pharmaceutical …},
volume = {62},
year = {2008}
}
@article{liu2018particle,
abstract = {A scale‐independent modeling approach based on the discrete element method has been established to investigate the development of pull‐apart basins. The main findings can be summarized as follows. Thirty degree underlapping models produce pull‐apart basins that},
author = {Liu, Yuan and Konietzky, Heinz},
cites = {11},
eprint = {https://agupubs.onlinelibrary.wiley.com/doi/pdf/10.1002/2017TC004685},
gsrank = {14},
journal = {Tectonics},
number = {1},
pages = {343--358},
publisher = {Wiley Online Library},
title = {Particle-based modeling of pull-apart basin development},
url = {https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1002/2017TC004685},
venue = {Tectonics},
volume = {37},
year = {2018}
}
@article{fazayeli2019towards,
abstract = {In recent years continuous integration has become an important practice for pull-based software development. It helps developers make contributions flexibly to an isolated copy of the project's repository, create a pull request that represent such changes, and submit it to},
author = {Fazayeli, Hassan and Syed-Mohamad, Sharifah Mashita and Akhir, Nur Shazwani Md},
cites = {1},
eprint = {https://www.sciencedirect.com/science/article/pii/S187705091931871X/pdf?md5=3f8c9369cf70b0fd6d014121af24724f&pid=1-s2.0-S187705091931871X-main.pdf},
gsrank = {15},
journal = {Procedia Computer Science},
pages = {585--592},
publisher = {Elsevier},
title = {Towards Auto-labelling Issue Reports for Pull-Based Software Development using Text Mining Approach},
url = {https://www.sciencedirect.com/science/article/pii/S187705091931871X},
venue = {Procedia Computer Science},
volume = {161},
year = {2019}
}
@inproceedings{zhang2020shoulders,
abstract = {Pull-based development is a widely adopted paradigm for collaboration in distributed software development, attracting eyeballs from both academic and industry. To better study pull-based development model, this paper presents a new dataset containing 96 features},
author = {Zhang, Xunhui and Rastogi, Ayushi and Yu, Yue},
booktitle = {Conference on Mining Software Repositories (MSR’20)},
cites = {0},
eprint = {https://www.researchgate.net/profile/Xunhui_Zhang/publication/342529857_On_the_Shoulders_of_Giants_A_New_Dataset_for_Pull-based_Development_Research/links/5ef9f1b7a6fdcc4ca43a419e/On-the-Shoulders-of-Giants-A-New-Dataset-for-Pull-based-Development-Research.pdf},
gsrank = {16},
title = {On the Shoulders of Giants: A New Dataset for Pull-based Development Research},
url = {https://www.researchgate.net/profile/Xunhui_Zhang/publication/342529857_On_the_Shoulders_of_Giants_A_New_Dataset_for_Pull-based_Development_Research/links/5ef9f1b7a6fdcc4ca43a419e/On-the-Shoulders-of-Giants-A-New-Dataset-for-Pull-based-Development-Research.pdf},
venue = {Conference on Mining Software …},
year = {2020}
}
@article{cocca2020two,
abstract = {Fluorescent organic molecules have received great attentiondue to theirlargest application, for example, at DNA and RNA spectroscopies studies, development of new photoluminescence bioprobes and applications in fluorescence spectroscopy. In specific},
author = {Cocca, Leandro HZ and Abegao, Luis MG and Sciuti, Lucas F and Vabre, Roxane and Siqueira, Jonathas Paula and Kamada, Kenji and Mendon{\c{c}}a, Cleber Renato and Piguel, Sandrine and De Boni, Leonardo},
cites = {0},
gsrank = {17},
journal = {The Journal of Physical Chemistry C},
publisher = {ACS Publications},
title = {Two-Photon Emissive Dyes Based on Push-Pull Purines Derivatives: Toward the Development of New Photoluminescence Bioprobes},
url = {https://pubs.acs.org/doi/abs/10.1021/acs.jpcc.0c01859},
venue = {The Journal of …},
year = {2020}
}
@article{shah2012development,
abstract = {Ropinirole hydrochloride is indicated in Parkinson's disease and Restless leg syndrome. In advanced Parkinson's disease the usual dose of Ropinirole hydrochloride is 0.25 to 5 mg three to four times a day. Hence, an attempt was made to develop a once-a-day controlled},
author = {Shah, Adarsh and Shah, Viral and Upadhyay, UM},
cites = {4},
eprint = {https://www.researchgate.net/profile/Viral_Shah17/publication/267824967_DEVELOPMENT_AND_EVALUATION_OF_PUSH-PULL_BASED_OSMOTIC_DELIVERY_SYSTEM_FOR_ROPINIROLE/links/551163740cf29a3bb71dabf0/DEVELOPMENT-AND-EVALUATION-OF-PUSH-PULL-BASED-OSMOTIC-DELIVERY-SYSTEM-FOR-ROPINIROLE.pdf},
gsrank = {18},
journal = {International Journal of Pharmaceutical Sciences and Research},
number = {9},
pages = {3211},
publisher = {International Journal of Pharmaceutical Sciences and Research},
title = {Development and evaluation of push-pull based osmotic delivery system for ropinirole},
url = {https://www.researchgate.net/profile/Viral_Shah17/publication/267824967_DEVELOPMENT_AND_EVALUATION_OF_PUSH-PULL_BASED_OSMOTIC_DELIVERY_SYSTEM_FOR_ROPINIROLE/links/551163740cf29a3bb71dabf0/DEVELOPMENT-AND-EVALUATION-OF-PUSH-PULL-BASED-OSMOTIC-DELIVERY-SYSTEM-FOR-ROPINIROLE.pdf},
venue = {International Journal of …},
volume = {3},
year = {2012}
}
@inproceedings{abd2008automated,
abstract = {This paper describes the processes of document downloading and announcement in the e-learning is automated via a proposed agent-based framework. In the framework, the interaction policy for the involved agents is based on combination technique which},
author = {Abd Latif, Norizal and Hassan, Mohd Fadzil and Hasan, Mohd Hilmi},
booktitle = {2008 International Symposium on Information Technology},
cites = {10},
gsrank = {19},
organization = {IEEE},
pages = {1--7},
title = {Automated notification and document downloading in E-learning-development of an agent-based framework utilizing the push-pull technology interaction policy},
url = {https://ieeexplore.ieee.org/abstract/document/4631569/},
venue = {… Symposium on Information …},
volume = {1},
year = {2008}
}
@article{sturm2011development,
abstract = {A novel linker chemistry based on a malondialdehyde− indole condensation reaction has been developed for the affinity-independent elution of targeted protein pull-downs. Previously developed in our lab for the tagging of tryptophan residues on proteins or},
author = {Sturm, Martin and Leitner, Alexander and Lindner, Wolfgang},
cites = {9},
gsrank = {20},
journal = {Bioconjugate chemistry},
number = {2},
pages = {211--217},
publisher = {ACS Publications},
title = {Development of an indole-based chemically cleavable linker concept for immobilizing bait compounds for protein pull-down experiments},
url = {https://pubs.acs.org/doi/abs/10.1021/bc100330a},
venue = {Bioconjugate chemistry},
volume = {22},
year = {2011}
}
@inproceedings{syed2019soready,
abstract = {Pull-based software development is a distributed development model that offers an opportunity to review a pull request before it gets merged into the main repository. A pull request addresses new features, bug fixing, and maintenance issues submitted by both},
author = {Syed-Mohamad, Sharifah Mashita and Akhir, Nur Shazwani Md},
booktitle = {2019 26th Asia-Pacific Software Engineering Conference (APSEC)},
cites = {0},
gsrank = {21},
organization = {IEEE},
pages = {9--14},
title = {SoReady: An Extension of the Test and Defect Coverage-Based Analytics Model for Pull-Based Software Development},
url = {https://ieeexplore.ieee.org/abstract/document/8945520/},
venue = {2019 26th Asia-Pacific …},
year = {2019}
}
@inproceedings{hu2006development,
abstract = {The paper introduces a DC-DC multiple converter based on push-pull forward topology and analyzes its operation principle in detail. It has some superiority in low voltage and high current situation. Then the design procedure of the power stage and control circuit is},
author = {Hu, Weihao and Pei, Yunqing and Wang, Zhaoan},
booktitle = {2006 CES/IEEE 5th International Power Electronics and Motion Control Conference},
cites = {5},
gsrank = {22},
organization = {IEEE},
pages = {1--4},
title = {Development of DC-DC multiple converter based on push-pull forward topology},
url = {https://ieeexplore.ieee.org/abstract/document/4777999/},
venue = {2006 CES/IEEE 5th International Power …},
volume = {1},
year = {2006}
}
@article{tambe2020evidence,
abstract = {Over the last few years, the bamboo policy in India has undergone a major change. The national bamboo development programme has been restructured with a shift in priority from restoring bamboo forests to promoting farm bamboo and developing its market linkage. This},
author = {Tambe, Sandeep and Patnaik, Suprava and Upadhyay, Anup P and Edgaonkar, Advait and Singhal, Rekha and Bisaria, Jigyasa and Srivastava, Pankaj and Hiralal, Mohan H and Dahake, Kailash and Gawande, Abhishek and others},
cites = {0},
eprint = {https://www.researchgate.net/profile/Sandeep_Tambe2/publication/341039649_Evidence-based_policy_for_bamboo_development_in_India_From_supply_push_to_demand_pull/links/5eaa3a2a299bf18b9587d1a4/Evidence-based-policy-for-bamboo-development-in-India-From-supply-push-to-demand-pull.pdf},
gsrank = {23},
journal = {Forest Policy and Economics},
pages = {102187},
publisher = {Elsevier},
title = {Evidence-based policy for bamboo development in India: From “supply push” to “demand pull”},
url = {https://www.sciencedirect.com/science/article/pii/S1389934120300435},
venue = {Forest Policy and …},
volume = {116},
year = {2020}
}
@inproceedings{azeem2020action,
abstract = {Pull requests (PRs) selection is a challenging task faced by integrators in pull-based development (PbD), with hundreds of PRs submitted on a daily basis to large open-source projects. Managing these PRs manually consumes integrators' time and resources and may},
author = {Azeem, Muhammad Ilyas and Panichella, Sebastiano and Di Sorbo, Andrea and Serebrenik, Alexander and Wang, Qing},
booktitle = {International Conference on Software and System Processes},
cites = {0},
eprint = {https://www.win.tue.nl/~aserebre/ICSSP2020.pdf},
gsrank = {24},
title = {Action-based Recommendation in Pull-request Development},
url = {https://www.win.tue.nl/~aserebre/ICSSP2020.pdf},
venue = {… on Software and …},
year = {2020}
}
@phdthesis{rathnayake2019interec,
abstract = {Over the last decade, open source software development, dramatically changed with the introduction of the pull-based development mechanism. The pull-based method became popular because of the convenience for collaborative contributions. With the introduction of},
author = {Rathnayake, Raveen Savinda},
cites = {0},
gsrank = {25},
title = {InteRec-Integrator Recommendation for Pull-Based Distributed Software Development},
url = {http://dlib.iit.ac.lk/xmlui/handle/123456789/308},
venue = {NA},
year = {2019}
}
@article{ogunseye2015development,
abstract = {Conventional power inverter systems are normally specified to work with a single nominal battery voltage. This is somewhat restrictive and causes downtimes when dc power sources of specified voltages are not available. In this work, a push-pull inverter circuit that generates},
author = {Ogunseye, Abiodun Alani and Titus, Ogunseye},
cites = {2},
eprint = {https://www.academia.edu/download/47175502/C010611620.pdf},
gsrank = {26},
journal = {OSR Journal of Electrical and Electronics Engineering (IOSR-JEEE)},
pages = {16--20},
title = {Development Of A Microcontroller Based 12/24 Volts Push-Pull Inverter System},
url = {https://www.academia.edu/download/47175502/C010611620.pdf},
venue = {OSR Journal of Electrical and Electronics …},
year = {2015}
}
@inproceedings{rathnayake2019review,
abstract = {Distributed Software development process has dramatically changed over the last decade due to the integration of social collaborative development environment. The pull-based software development methodology made its mark in the open source distributed},
author = {Rathnayake, Raveen Savinda and Poravi, Guhanathan},
booktitle = {2019 IEEE 5th International Conference for Convergence in Technology (I2CT)},
cites = {0},
gsrank = {27},
organization = {IEEE},
pages = {1--5},
title = {Review on Textual Data Mining for Reviewer Recommendation in Pull-Based Distributed Software Development},
url = {https://ieeexplore.ieee.org/abstract/document/9033820/},
venue = {2019 IEEE 5th International …},
year = {2019}
}
@misc{gousios2015work,
author = {Gousios, G and Zaidman, A and Storey, M and Deursen, A v},
cites = {2},
gsrank = {28},
title = {Work Practices and Challenges in Pull-Based Development: The Integrator’s Perspective. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Vol. 1. 358--368},
venue = {NA},
year = {2015}
}
@inproceedings{gousios2013exploration,
author = {Gousios, G and Pinzger, M and Van Deursen, A},
booktitle = {ICSE},
cites = {8},
gsrank = {29},
pages = {2568225--2568260},
title = {An exploration of the pull-based software development model},
venue = {NA},
volume = {10},
year = {2013}
}
@article{ogunseye2016development,
abstract = {Some measures of merit of an inverter system are the total harmonic distortion and the efficiency figures. On one hand, we have square wave and modified square wave inverters that have high efficiency and total harmonic distortion (THD) figures. On the other hand},
author = {Ogunseye, Abiodun Alani and Ogunseye, Taofik Titus},
cites = {0},
eprint = {https://www.ojs.jctecs.com/index.php/com/article/viewFile/106/43},
gsrank = {30},
journal = {Journal of Communications Technology, Electronics and Computer Science},
pages = {12--16},
title = {Development of a Microcontroller Based Low Distortion Modified Push-Pull Power Inverter},
url = {https://www.ojs.jctecs.com/index.php/com/article/view/106},
venue = {Journal of Communications …},
volume = {6},
year = {2016}
}
@article{liu2018particle,
abstract = {Pull-apart basins form in extensional structures or releasing sidesteps and bends where a left-lateral strike-slip fault steps to the left or a right-lateral fault steps to the right [Fossen, 2016]. A pull-apart basin can evolve from different initial fault geometries (30 underlapping},
author = {Liu, Yuan and Konietzky, Heinz},
cites = {0},
gsrank = {31},
journal = {EGUGA},
pages = {12728},
title = {Particle based modeling of pull-apart basin development with different initial master fault configurations},
url = {https://ui.adsabs.harvard.edu/abs/2018EGUGA..2012728L/abstract},
venue = {EGUGA},
year = {2018}
}
@phdthesis{husseini2018development,
abstract = {Recent RF applications and research require thousands of accurate measurements to be performed within a practical time. For instance, the global model extraction of a DUT requires thousands of accurate measurements, which would take a very long time when},
author = {Husseini, Thoalfukar},
cites = {0},
eprint = {http://orca.cf.ac.uk/119018/1/2019HusseiniTHAPhD.pdf},
gsrank = {32},
school = {Cardiff University},
title = {On the development and automation of a high-speed load-pull system based on Pxie modules},
url = {http://orca.cf.ac.uk/id/eprint/119018},
venue = {NA},
year = {2018}
}
@inproceedings{zhang2012development,
abstract = {After introduced the characteristics of the current development of industrial technology and after the detailed descriptions of the basic principle of OPC technology, the real-time communication between Personal Computer and S7-200 PLC had been achieved by using},
author = {Zhang, Fei and Ding, Hong and Yao, Bao-Guo},
booktitle = {Proceedings of the 2012 Second International Conference on Electric Information and Control Engineering-Volume 03},
cites = {0},
gsrank = {33},
pages = {371--374},
title = {Development and Design of the Pull Detection System Based on OPC Program},
url = {https://dl.acm.org/doi/abs/10.5555/2452572.2453957},
venue = {… of the 2012 Second International Conference …},
year = {2012}
}
@article{valilainovel,
abstract = {Nowadays, manufacturing organizations face with increasing pressures from the frequent changes in product type, continuous demand fluctuations and unexpected changes in customer requirements. In order to survive in this turbulent environment, manufacturing},
author = {Valilai, Omid Fatahi and Kivi, Hossein Reyhani},
cites = {0},
eprint = {http://www.academia.edu/download/52429690/IJOER-MAR-2017-2.pdf},
gsrank = {34},
title = {A novel framework for a pull oriented product development and planning based on Quality Function Deployment},
url = {http://www.academia.edu/download/52429690/IJOER-MAR-2017-2.pdf},
venue = {NA},
year = {NA}
}
@inproceedings{yeom2005development,
abstract = {In this study, the progressive failure and creep of the traditional ground anchor structure were decreased and a new ground anchor that can attain the required pull-out resistance even in soft sandy soils with low confining pressure was developed. Ground anchors are},
author = {Yeom, Ho-Hyeong and Im, Jong-Chul and Hong, Seok-Woo and Kim, Chul-Ung and Shin, Chul-Sung},
booktitle = {Proceedings of the Korean Geotechical Society Conference},
cites = {0},
gsrank = {35},
organization = {Korean Geotechnical Society},
pages = {788--795},
title = {Development of Composite Tension. Compression Anchor System based on the pull out resistance characteristics of Ground Anchor},
url = {https://www.koreascience.or.kr/article/CFKO200533239331687.page},
venue = {Proceedings of the …},
year = {2005}
}
@article{gousios2014exploration,
author = {Gousios, G and Pinzger, M and Deursen, A},
cites = {2},
gsrank = {36},
journal = {Submitted to the ICSE},
title = {An exploration of the pull-based software development model. sep 2013},
venue = {NA},
year = {2014}
}
@inproceedings{gousios2014exploration,
author = {Gousios, G and Pinzger, M and van Deursen, A},
booktitle = {ICSE},
cites = {2},
gsrank = {37},
pages = {2568225--2568260},
title = {An exploration of the pull-based software development model. June 2014},
venue = {NA},
volume = {10},
year = {2014}
}
@article{an2014based,
abstract = { The EU pull has introduced an element of competition, peer pressure between countries involved in this field. No country likes to be seen as lagging behind in areas («naming and shaming»). This element of peer pressure became apparent in the early phases of EQF},
author = {An, EOSE},
cites = {0},
gsrank = {38},
journal = {Sport: Linking Education, Training and Employment in Europe: An EOSE Network Perspective},
pages = {37},
publisher = {Presses universitaires de Louvain},
title = {Based on Cedefop’s work (European Centre for the Development of Vocational Training) in the development and implementation of the tools, we have been able to observe the strengths as well as the weaknesses of the European pull activated in this field. One of the strongest influences of European policies in education and training is},
url = {https://books.google.com/books?hl=en&lr=&id=cTDfBgAAQBAJ&oi=fnd&pg=PA37&dq=pull+based+development&ots=55ZwUh9pRQ&sig=JkbdGGgYHozUiX8mb5JIB9drnmg},
venue = {Sport: Linking Education, Training and Employment in …},
year = {2014}
}
@inproceedings{gousiosvan,
author = {Gousios, G and Zaidman, A and Storey, MA},
booktitle = {37th IEEE International Conference on Software Engineering (ICSE)},
cites = {2},
gsrank = {39},
pages = {358--368},
title = {van Arie Deursen (2015). Work practices and challenges in pull-based development: the integrator’s perspective},
venue = {NA},
year = {NA}
}
@article{saito2016git,
abstract = {DSpace/Manakin Repository git-sprite:Supporting Tool for Pull-Based Software Development Model JavaScript is disabled for your browser. Some features of this site may not work without it. git-sprite:Supporting Tool for Pull-Based Software Development Model. Saito, Yusuke},
author = {Saito, Yusuke},
cites = {0},
gsrank = {40},
publisher = {奈良先端科学技術大学院大学},
title = {git-sprite: Supporting Tool for Pull-Based Software Development Model},
url = {https://library.naist.jp/dspace/handle/10061/10536},
venue = {NA},
year = {2016}
}
@article{lin20061,
author = {Lin-jun, WANG},
cites = {2},
gsrank = {41},
journal = {Manufacture Information Engineering of China},
title = {1, LI Shang-ping\~{} 2, LIANG Shi\~{} 1, YANG Nian-jiong\~{} 2 (1. Guangxi University, Guangxi Nanning, 530004, China)(2. Guangxi University of Technology, Guangxi Liuzhou, 545006, China); The Development of MIS for Automobile Parts Providers Based on Pull Lists [J]},
venue = {NA},
volume = {21},
year = {2006}
}
@article{lee2015study,
author = {Lee, JM},
cites = {2},
gsrank = {42},
journal = {Konkuk University},
title = {A study on development of the load resistance test evaluation method of lightweight wall against wall attachments: based on the forms of eccentric pull [master’s thesis]},
venue = {NA},
year = {2015}
}
@phdthesis{camara1993development,
author = {Camara, Julian},
cites = {0},
gsrank = {43},
school = {Texas A \& I University},
title = {Development of a pull based production scheduling and inventory management system to achieve JIT for a radio assembly line},
venue = {NA},
year = {1993}
}
@article{yin2011analysis,
abstract = {On the basis of analyzing the development prospects of China and advantages of the drop and pull transport of Nantong, the paper discusses the difficulties in developing the container drop and pull transport of Nantong, and presents some corresponding},
author = {Yin-fen, LIU},
cites = {1},
gsrank = {44},
journal = {Journal of Nantong Vocational \& Technical Shipping College},
title = {An Analysis of Development of Nantong Container Drop and Pull Transport Based on the Twelfth 5-Year Plan},
url = {http://en.cnki.com.cn/Article_en/CJFDTotal-NTHY201102006.htm},
venue = {Journal of Nantong Vocational & Technical Shipping …},
volume = {2},
year = {2011}
}
@misc{zhang2014investigating,
author = {Zhang, Y and Yin, G and Yu, Y and Wang, H},
cites = {0},
gsrank = {45},
title = {Investigating social media in GitHub’s pull-requests: a case study on Ruby on Rails. Proceedings of the 1st International Workshop on Crowd-based Software Development Methods and Technologies. Hong Kong: ACM},
venue = {NA},
year = {2014}
}
@phdthesis{matros2016entwicklung,
author = {Matros, Kevin},
cites = {1},
gsrank = {46},
school = {Karlsruher Institut f{\"u}r Technologie (KIT)},
title = {Entwicklung von Hybridantriebssystemen auf Basis des Pull-Prinzips der Validierung und des IPEK-X-in-the-Loop-Ansatzes: Development of hybrid powertrain systems based on the validation pull-principle and the IPEK-X-in-the-Loop-approach},
venue = {NA},
year = {2016}
}
Process finished with exit code 0

213
experiment/study-search/gs-3.bib Normal file
View File

@ -0,0 +1,213 @@
@inproceedings{ren2019identifying,
abstract = {Fork-based development is popular and easy to use, but makes it difficult to maintain an overview of the whole community when the number of forks increases. This may lead to redundant development where multiple developers are solving the same problem in parallel},
author = {Ren, Luyao and Zhou, Shurui and K{\"a}stner, Christian and W{\k{a}}sowski, Andrzej},
booktitle = {2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
cites = {8},
eprint = {https://pure.itu.dk/portal/files/83700892/main_5_.pdf},
gsrank = {1},
organization = {IEEE},
pages = {230--241},
title = {Identifying redundancies in fork-based development},
url = {https://ieeexplore.ieee.org/abstract/document/8668023/},
venue = {2019 IEEE 26th …},
year = {2019}
}
@inproceedings{zhou2019improving,
abstract = {Fork-based development is a lightweight mechanism that allows developers to collaborate with or without explicit coordination. Although it is easy to use and popular, when developers each create their own fork and develop independently, their contributions are usually not},
author = {Zhou, Shurui},
booktitle = {2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE)},
cites = {0},
eprint = {http://www.eecg.toronto.edu/~shuruiz/paper/PhDThesis-ShuruiZhou.pdf},
gsrank = {2},
organization = {IEEE},
pages = {1218--1221},
title = {Improving collaboration efficiency in fork-based development},
url = {https://ieeexplore.ieee.org/abstract/document/8952395/},
venue = {2019 34th IEEE/ACM International Conference on …},
year = {2019}
}
@article{oiko2014development,
abstract = {Understanding the mechanical properties of nanoscale systems requires new experimental and theoretical tools. In particular, force sensors compatible with nanomechanical testing experiments and with sensitivity in the nN range are required. Here, we report the},
author = {Oiko, VTA and Martins, BVC and Silva, PC and Rodrigues, V and Ugarte, D},
cites = {7},
eprint = {http://repositorio.unicamp.br/bitstream/REPOSIP/201279/1/pmed_24689612.pdf},
gsrank = {3},
journal = {Review of Scientific Instruments},
number = {3},
pages = {035003},
publisher = {American Institute of Physics},
title = {Development of a quartz tuning-fork-based force sensor for measurements in the tens of nanoNewton force range during nanomanipulation experiments},
url = {https://aip.scitation.org/doi/abs/10.1063/1.4868236},
venue = {Review of Scientific …},
volume = {85},
year = {2014}
}
@inproceedings{carullo2016development,
abstract = {This work investigates the response to humidity of Quartz Tuning Forks (QTFs) coated with a sol-gel iron-doped amorphous magnesium silicate sensing film. Thanks to the reduced film thickness, the investigated sensors exploit a short time response thus being suitable for},
author = {Carullo, Alessio and Vallan, Alberto and Afify, Ahmed S and Tulliani, J-M},
booktitle = {2016 IEEE International Instrumentation and Measurement Technology Conference Proceedings},
cites = {2},
gsrank = {4},
organization = {IEEE},
pages = {1--6},
title = {Development of a fast humidity sensor based on quartz tuning fork},
url = {https://ieeexplore.ieee.org/abstract/document/7520375/},
venue = {2016 IEEE International …},
year = {2016}
}
@misc{kolm2006development,
abstract = {Under an agreement with Pitkin County, Hydrologic Systems Analysis, LLC (HSA) of Golden, Colorado, in cooperation with Heath Hydrology, Inc.(HHI) of Boulder, Colorado, created a GIS-based step-wise ground water resources evaluation procedure for use as decision/land},
author = {Kolm, Kenneth E and van der Heijde, Paul KM},
cites = {2},
eprint = {https://www.pitkincountyrivers.com/uploads/1/0/3/1/10319041/upper_and_middle_roaring_fork_final.pdf},
gsrank = {5},
publisher = {Report prepared by HSA and HHI for Pitkin County Commission of County~…},
title = {DEVELOPMENT OF GIS-BASED GROUND WATER RESOURCES EVALUATION OF THE UPPER AND MIDDLE ROARING FORK VALLEY AREA, PITKIN COUNTY, COLORADO},
url = {https://www.pitkincountyrivers.com/uploads/1/0/3/1/10319041/upper_and_middle_roaring_fork_final.pdf},
venue = {NA},
year = {2006}
}
@article{stanciulescuvariability,
abstract = {While there are systematic product line engineering methodologies that support variability (eg, preprocessor, deltas, aspects, modules), software variants are often developed using clone-and-own (aka copy-paste) since it is a low-cost mechanism without a steep learning},
author = {Stanciulescu, Stefan},
cites = {0},
eprint = {http://blog.ieeesoftware.org/2015/},
gsrank = {6},
title = {Variability Management using Github fork-based development},
url = {http://blog.ieeesoftware.org/2015/},
venue = {NA},
year = {NA}
}
@inproceedings{xu2008development,
abstract = {Article Preview Article Preview Article Preview This paper presents a high precision temperature measurement instrument based on quartz tuning-fork temperature sensor (QTTS) using Artificial Neural Networks (ANN). The advantage of QTTS is a great sensitivity},
author = {Xu, Jun and You, Bo and Li, X},
booktitle = {Key Engineering Materials},
cites = {1},
eprint = {http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1020.1217&rep=rep1&type=pdf},
gsrank = {7},
organization = {Trans Tech Publ},
pages = {477--480},
title = {Development of a High-Precision Temperature Measurement Instrument Based on Quartz Tuning-Fork Temperature Sensor},
url = {https://www.scientific.net/KEM.381-382.477},
venue = {Key Engineering Materials},
volume = {381},
year = {2008}
}
@article{jalilian2014development,
abstract = {This article reports on the development of tuning fork-based AFM/STM probes in NaugaNeedles LLC for use in atomic force microscopy. These probes can be mounted on different carriers per customers' request.(eg, RHK carrier, Omicron carrier, and tuning fork on},
author = {Jalilian, Romaneh and Yazdanpanah, Mehdi M and Torrez, Neil and Alizadeh, Amirali and Askari, Davood},
cites = {0},
gsrank = {8},
journal = {APS},
pages = {H1--367},
title = {Development of Tuning Fork Based Probes for Atomic Force Microscopy},
url = {https://ui.adsabs.harvard.edu/abs/2014APS..MAR.H1367J/abstract},
venue = {APS},
volume = {2014},
year = {2014}
}
@article{tungdevelopment,
abstract = {We describe the development of Fork-AFM for investigating of human blood cell morphology, namely erythrocytes with high-resolution imaging. The measurements were compared with Fork-AFM using silicon cantilever tip on erythrocytes for two modes},
author = {Tung, Vo Thanh},
cites = {0},
eprint = {http://microtm.narod.ru/byspm/2008/pdf/byspm2008-26-p142-147.pdf},
gsrank = {9},
title = {DEVELOPMENT OF A TUNING FORK BASED ATOMIC FORCE MICROSCOPY (FORK-AFM) FOR IMAGING ON ERYTHROCYTES},
url = {http://microtm.narod.ru/byspm/2008/pdf/byspm2008-26-p142-147.pdf},
venue = {NA},
year = {NA}
}
@article{oikodevelopment,
abstract = {We describe the development of a force sensor to be coupled to a home-built manipulator operating inside a scanning electron microscope. We aim to perform force measurements during in-situ manipulation of nano-objects. The sensor is based on a quartz tuning fork due},
author = {Oiko, V},
cites = {0},
eprint = {https://www.sbpmat.org.br/icam2009dir/submission/autor/arquivos/B529.pdf},
gsrank = {10},
title = {Development of a tuning fork based sensor for in-situ force measurements during nanomanipulation inside a high resolution SEM. V. Oiko (, BVC Martins (2), V. Rodrigues (2) and D. Ugarte (2)},
url = {https://www.sbpmat.org.br/icam2009dir/submission/autor/arquivos/B529.pdf},
venue = {NA},
year = {NA}
}
@article{kolm2007development,
author = {KOLM, Kenneth E},
cites = {0},
gsrank = {11},
title = {DEVELOPMENT OF GIS-BASED SUSTAINABLE GROUND WATER RESOURCES EVALUATION OF THE UPPER AND MIDDLE ROARING FORK AREA, PITKIN COUNTY, COLORADO},
venue = {NA},
year = {2007}
}
@article{oiko2014v,
author = {Oiko, VTA and Martins, BVC and Silva, PC},
cites = {2},
gsrank = {12},
journal = {Review of Scientific Instruments},
number = {3},
pages = {035003},
title = {V. Rodrigues et D. Ugarte. Development of a quartz tuning-fork-based force sensor for measurements in the tens of nanoNewton force range during nanomanipulation experiments},
venue = {NA},
volume = {85},
year = {2014}
}
@phdthesis{townsend2013development,
author = {Townsend, JR},
cites = {2},
gsrank = {13},
school = {MS thesis. Nottingham: University of Nottingham},
title = {The development of a geomatics-based toolkit to assess the impact of engineered grade building structures on the North Fork Toutle River, Mt. St. Helens},
venue = {NA},
year = {2013}
}
@article{westerhoff2008proof,
author = {Westerhoff, Paul and Tao, Nongjian and Guzman, Roberto and Kruger, KC and Tsow, Francis and Forzani, Erica},
cites = {0},
gsrank = {14},
title = {Proof-of-Concept Development of a Microfabricated Tuning-Fork Based Sensor for Disinfection By-products in drinking water},
venue = {NA},
year = {2008}
}
@article{wu2008research,
abstract = {According to the powerful function of Pro/E and the Pro/Toolkit which is secondly developed module, and taking Visual C++ as developed platform, the software combines object-oriented technology and process-oriented technology and takes DLL format, and realizes},
author = {WU, Bo and WEI, Liang-bao},
cites = {0},
gsrank = {15},
journal = {Taiyuan Science \& Technology},
number = {6},
pages = {37},
title = {Research and Development of Fork Parameterized Design System Based on Pro/E},
url = {http://en.cnki.com.cn/Article_en/CJFDTotal-TAIY200806037.htm},
venue = {Taiyuan Science & Technology},
year = {2008}
}
Process finished with exit code 0

0
study-search/ieee.bib → experiment/study-search/ieee.bib
View File

684
experiment/study-search/papers-1.bib Normal file
View File

@ -0,0 +1,684 @@
@article{10.1007/s10664-019-09756-z,
author = {Hora, Aline BritoMarco Tulio ValenteLaerte XavierAndre},
doi = {10.1007/s10664-019-09756-z},
journal = {Empirical Software Engineering},
number = {2},
title = {{You broke my code: understanding the motivations for breaking changes in APIs}},
url = {http://link.springer.com/article/10.1007/s10664-019-09756-z},
volume = {25},
year = {2020}
}
@inproceedings{10.5555/2818754.2818800,
abstract = {In the pull-based development model, the integrator has the crucial role of managing and integrating contributions. This work focuses on the role of the integrator and investigates working habits and challenges alike. We set up an exploratory qualitative study involving a large-scale survey of 749 integrators, to which we add quantitative data from the integrator's project. Our results provide insights into the factors they consider in their decision making process to accept or reject a contribution. Our key findings are that integrators struggle to maintain the quality of their projects and have difficulties with prioritizing contributions that are to be merged. Our insights have implications for practitioners who wish to use or improve their pull-based development process, as well as for researchers striving to understand the theoretical implications of the pull-based model in software development.},
author = {Gousios, Georgios and Zaidman, Andy and Storey, Margaret-Anne and van Deursen, Arie},
booktitle = {Proceedings of the 37th International Conference on Software Engineering - Volume 1},
isbn = {9781479919345},
pages = {358--368},
publisher = {IEEE Press},
series = {ICSE '15},
title = {{Work Practices and Challenges in Pull-Based Development: The Integrator's Perspective}},
year = {2015}
}
@inproceedings{10.1145/2884781.2884826,
abstract = {The pull-based development model is an emerging way of contributing to distributed software projects that is gaining enormous popularity within the open source software (OSS) world. Previous work has examined this model by focusing on projects and their owners---we complement it by examining the work practices of project contributors and the challenges they face.We conducted a survey with 645 top contributors to active OSS projects using the pull-based model on GitHub, the prevalent social coding site. We also analyzed traces extracted from corresponding GitHub repositories. Our research shows that: contributors have a strong interest in maintaining awareness of project status to get inspiration and avoid duplicating work, but they do not actively propagate information; communication within pull requests is reportedly limited to low-level concerns and contributors often use communication channels external to pull requests; challenges are mostly social in nature, with most reporting poor responsiveness from integrators; and the increased transparency of this setting is a confirmed motivation to contribute. Based on these findings, we present recommendations for practitioners to streamline the contribution process and discuss potential future research directions.},
address = {New York, NY, USA},
author = {Gousios, Georgios and Storey, Margaret-Anne and Bacchelli, Alberto},
booktitle = {Proceedings of the 38th International Conference on Software Engineering},
doi = {10.1145/2884781.2884826},
isbn = {9781450339001},
keywords = { GitHub, open source contribution, pull request, pull-based development,distributed software development},
pages = {285--296},
publisher = {Association for Computing Machinery},
series = {ICSE '16},
title = {{Work Practices and Challenges in Pull-Based Development: The Contributor's Perspective}},
url = {https://doi.org/10.1145/2884781.2884826},
year = {2016}
}
@article{10.1007/s11771-019-4185-5,
author = {王怀民, Qiang Fan 范强Tao Wang 王涛Cheng Yang 杨程Gang Yin 尹刚Yue Yu 余跃Huai-min Wang},
doi = {10.1007/s11771-019-4185-5},
journal = {Journal of Central South University},
number = {9},
title = {{Why do they ask? An exploratory study of crowd discussions about Android application programming interface in stack overflow}},
url = {http://link.springer.com/article/10.1007/s11771-019-4185-5},
volume = {26},
year = {2019}
}
@article{10.1007/s10664-016-9436-6,
author = {Zhang, Jing JiangDavid LoJiahuan HeXin XiaPavneet Singh KochharLi},
doi = {10.1007/s10664-016-9436-6},
journal = {Empirical Software Engineering},
number = {1},
title = {{Why and how developers fork what from whom in GitHub}},
url = {http://link.springer.com/article/10.1007/s10664-016-9436-6},
volume = {22},
year = {2017}
}
@article{10.1007/s10664-019-09728-3,
author = {Filkov, David KavalerPremkumar DevanbuVladimir},
doi = {10.1007/s10664-019-09728-3},
journal = {Empirical Software Engineering},
number = {6},
title = {{Whom are you going to call? determinants of @-mentions in Github discussions}},
url = {http://link.springer.com/article/10.1007/s10664-019-09728-3},
volume = {24},
year = {2019}
}
@inproceedings{Yu2014,
abstract = {Github facilitates the pull-request mechanism as an outstanding social coding paradigm by integrating with social media. The review process of pull-requests is a typical crowd sourcing job which needs to solicit opinions of the community. Recommending appropriate reviewers can reduce the time between the submission of a pull-request and the actual review of it. In this paper, we firstly extend the traditional Machine Learning (ML) based approach of bug triaging to reviewer recommendation. Furthermore, we analyze social relations between contributors and reviewers, and propose a novel approach to recommend highly relevant reviewers by mining comment networks (CN) of given projects. Finally, we demonstrate the effectiveness of these two approaches with quantitative evaluations. The results show that CN-based approach achieves a significant improvement over the ML-based approach, and on average it reaches a precision of 78{\%} and 67{\%} for top-1 and top-2 recommendation respectively, and a recall of 77{\%} for top-10 recommendation.},
author = {Yu, Y and Wang, H and Yin, G and Ling, C X},
booktitle = {2014 21st Asia-Pacific Software Engineering Conference},
doi = {10.1109/APSEC.2014.57},
isbn = {1530-1362 VO - 1},
keywords = {CN-based approach,Comment Network,Communities,Encoding,Github,ML-based approach,Mathematical model,Pull-request,Rails,Reviewer Recommendation,Social Coding,Social network services,Software,Training,bug triaging,comment networks mining,crowd collaboration,crowdsourcing job,data mining,learning (artificial intelligence),machine learning based approach,program debugging,pull-request mechanism,recommender systems,reviewer recommendation,social media,social networking (online)},
pages = {335--342},
title = {{Who Should Review this Pull-Request: Reviewer Recommendation to Expedite Crowd Collaboration}},
volume = {1},
year = {2014}
}
@article{DBLP:journals/jss/JiangLZXYZ19,
author = {Jiang, Jing and Lo, David and Zheng, Jiateng and Xia, Xin and Yang, Yun and Zhang, Li},
doi = {10.1016/j.jss.2019.04.055},
journal = {J. Syst. Softw.},
pages = {196--210},
title = {{Who should make decision on this pull request? Analyzing time-decaying relationships and file similarities for integrator prediction}},
url = {https://doi.org/10.1016/j.jss.2019.04.055},
volume = {154},
year = {2019}
}
@article{DBLP:journals/infsof/JiangYHBZ17,
author = {Jiang, Jing and Yang, Yun and He, Jia-Huan and Blanc, Xavier and Zhang, Li},
doi = {10.1016/j.infsof.2016.10.006},
journal = {Inf. Softw. Technol.},
pages = {48--62},
title = {{Who should comment on this pull request? Analyzing attributes for more accurate commenter recommendation in pull-based development}},
url = {https://doi.org/10.1016/j.infsof.2016.10.006},
volume = {84},
year = {2017}
}
@inproceedings{10.1145/3195836.3195858,
abstract = {Although many software companies have recently embraced Open Source Software (OSS) initiatives, volunteers (i.e., developers who contribute to OSS in their spare time) still represent a wealthy workforce that have the potential of driving many non-trivial open source projects. Such volunteers face well-known barriers when attempting to contribute to OSS projects. However, what is still unclear is how the problems that volunteers face transcend to the problems that employees (i.e., developers hired by a software company to work on OSS projects) face. In this paper we aim to investigate the differences on the acceptance of patches submitted by volunteers and employees to company-owned OSS projects. We explore different characteristics of the patches submitted to company-owned OSS project, including: the frequency of acceptance and rejection; the total time to review and process a patch, and; whether the changes proposed follow some contribution best practices. We found that volunteers face 26X more rejections than employees. Volunteers have to wait, on average, 11 days to have a patch processed (employees wait 2 days, on average). 92{\%} of the dormant pull-requests (e.g., pull-requests that take too long to be processed) were submitted by employees. Finally, we observed that the best practices that had the patches are most adherent to is "commit messages need to be written in English."},
address = {New York, NY, USA},
author = {Pinto, Gustavo and Dias, Luiz Felipe and Steinmacher, Igor},
booktitle = {Proceedings of the 11th International Workshop on Cooperative and Human Aspects of Software Engineering},
doi = {10.1145/3195836.3195858},
isbn = {9781450357258},
keywords = { employees, volunteers,company-owned OSS projects},
pages = {110--113},
publisher = {Association for Computing Machinery},
series = {CHASE '18},
title = {{Who Gets a Patch Accepted First? Comparing the Contributions of Employees and Volunteers}},
url = {https://doi.org/10.1145/3195836.3195858},
year = {2018}
}
@article{10.1186/s13173-018-0079-x,
author = {Pinto, Luis Felipe DiasIgor SteinmacherGustavo},
doi = {10.1186/s13173-018-0079-x},
journal = {Journal of the Brazilian Computer Society},
number = {1},
title = {{Who drives company-owned OSS projects: internal or external members?}},
url = {http://link.springer.com/article/10.1186/s13173-018-0079-x},
volume = {24},
year = {2018}
}
@article{arXiv:2003.01153,
abstract = {Abstract: Background: Pull Request (PR) Integrators often face challenges in terms of multiple concurrent PRs, so the ability to gauge which of the PRs will get accepted can help them balance their workload. PR creators would benefit from knowing if certain characteristics of their PRs may increase the chances of acceptance. Aim: We modeled the probability that a PR will be accepted within a month after creation using a Random Forest model utilizing 50 predictors representing properties of the author, PR, and the project to which PR is submitted. Method: 483,988 PRs from 4218 popular NPM packages were analysed and we selected a subset of 14 predictors sufficient for a tuned Random Forest model to reach high accuracy. Result: An AUC-ROC value of 0.95 was achieved predicting PR acceptance. The model excluding PR properties that change after submission gave an AUC-ROC value of 0.89. We tested the utility of our model in practical scenarios by training it with historical data for the NPM package $\backslash$textit{\{}bootstrap{\}} and predicting if the PRs submitted in future will be accepted. This gave us an AUC-ROC value of 0.94 with all 14 predictors, and 0.77 excluding PR properties that change after its creation. Conclusion: PR integrators can use our model for a highly accurate assessment of the quality of the open PRs and PR creators may benefit from the model by understanding which characteristics of their PRs may be undesirable from the integrators' perspective. The model can be implemented as a tool, which we plan to do as a future work. △ Less},
author = {{Authors: Tapajit Dey}, Audris Mockus},
journal = {arXiv preprint arXiv:2003.01153},
title = {{Which Pull Requests Get Accepted and Why? A study of popular NPM Packages}},
year = {2020}
}
@inproceedings{10.1145/3196398.3196429,
abstract = {Open-source software (OSS) often evolves from volunteer contributions, so OSS development teams must cooperate with their communities to attract new developers. However, in view of the myriad ways that developers interact over platforms for OSS development, observers of these communities may have trouble discerning, and thus learning from, the successful patterns of developer-to-team interactions that lead to eventual team acceptance. In this work, we study project communities on GitHub to discover which forms of software contribution characterize developers who begin as development team outsiders and eventually join the team, in contrast to developers who remain team outsiders. From this, we identify and compare the forms of contribution, such as pull requests and several forms of discussion comments, that influence whether new developers join OSS teams, and we discuss the implications that these behavioral patterns have for the focus of designers and educators.},
address = {New York, NY, USA},
author = {Middleton, Justin and Murphy-Hill, Emerson and Green, Demetrius and Meade, Adam and Mayer, Roger and White, David and McDonald, Steve},
booktitle = {Proceedings of the 15th International Conference on Mining Software Repositories},
doi = {10.1145/3196398.3196429},
isbn = {9781450357166},
pages = {403--413},
publisher = {Association for Computing Machinery},
series = {MSR '18},
title = {{Which Contributions Predict Whether Developers Are Accepted into Github Teams}},
url = {https://doi.org/10.1145/3196398.3196429},
year = {2018}
}
@inproceedings{10.1145/3338906.3338918,
abstract = {Forking and pull requests have been widely used in open-source communities as a uniform development and contribution mechanism, giving developers the flexibility to modify their own fork without affecting others before attempting to contribute back. However, not all projects use forks efficiently; many experience lost and duplicate contributions and fragmented communities. In this paper, we explore how open-source projects on GitHub differ with regard to forking inefficiencies. First, we observed that different communities experience these inefficiencies to widely different degrees and interviewed practitioners to understand why. Then, using multiple regression modeling, we analyzed which context factors correlate with fewer inefficiencies.We found that better modularity and centralized management are associated with more contributions and a higher fraction of accepted pull requests, suggesting specific best practices that project maintainers can adopt to reduce forking-related inefficiencies in their communities.},
address = {New York, NY, USA},
author = {Zhou, Shurui and Vasilescu, Bogdan and K{\"{a}}stner, Christian},
booktitle = {Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering},
doi = {10.1145/3338906.3338918},
isbn = {9781450355728},
keywords = { Centralized Management, Collaboration efficiency, Fork-based development,Modularity},
pages = {350--361},
publisher = {Association for Computing Machinery},
series = {ESEC/FSE 2019},
title = {{What the Fork: A Study of Inefficient and Efficient Forking Practices in Social Coding}},
url = {https://doi.org/10.1145/3338906.3338918},
year = {2019}
}
@article{DBLP:journals/infsof/SoaresJPM18,
author = {Soares, Daric{\'{e}}lio Moreira and {de Lima J{\'{u}}nior}, Manoel Limeira and Plastino, Alexandre and Murta, Leonardo},
doi = {10.1016/j.infsof.2018.01.015},
journal = {Inf. Softw. Technol.},
pages = {32--43},
title = {{What factors influence the reviewer assignment to pull requests?}},
url = {https://doi.org/10.1016/j.infsof.2018.01.015},
volume = {98},
year = {2018}
}
@article{10.1007/s10664-020-09819-6,
author = {Xia, Junxiao HanEmad ShihabZhiyuan WanShuiguang DengXin},
doi = {10.1007/s10664-020-09819-6},
journal = {Empirical Software Engineering},
number = {4},
title = {{What do Programmers Discuss about Deep Learning Frameworks}},
url = {http://link.springer.com/article/10.1007/s10664-020-09819-6},
volume = {25},
year = {2020}
}
@inproceedings{10.1145/3196321.3196357,
abstract = {When contributing code to a software system, developers are often confronted with the hard task of understanding and adhering to the system's design. This task is often made more difficult by the lack of explicit design information. Often, recorded design information occurs only embedded in discussions between developers. If this design information could be identified automatically and put into a form useful to developers, many development tasks could be eased, such as directing questions that arise during code review, tracking design changes that might affect desired system qualities, and helping developers understand why the code is as it is. In this paper, we take an initial step towards this goal, considering how design information appears in pull request discussions and manually categorizing 275 paragraphs from those discussions that contain design information to learn about what kinds of design topics are discussed.},
address = {New York, NY, USA},
author = {Viviani, Giovanni and Janik-Jones, Calahan and Famelis, Michalis and Xia, Xin and Murphy, Gail C},
booktitle = {Proceedings of the 26th Conference on Program Comprehension},
doi = {10.1145/3196321.3196357},
isbn = {9781450357142},
pages = {328--331},
publisher = {Association for Computing Machinery},
series = {ICPC '18},
title = {{What Design Topics Do Developers Discuss?}},
url = {https://doi.org/10.1145/3196321.3196357},
year = {2018}
}
@article{DBLP:journals/jcst/LiYYWW17,
author = {Li, Zhixing and Yu, Yue and Yin, Gang and Wang, Tao and Wang, Huaimin},
doi = {10.1007/s11390-017-1783-2},
journal = {J. Comput. Sci. Technol.},
number = {6},
pages = {1060--1075},
title = {{What Are They Talking About? Analyzing Code Reviews in Pull-Based Development Model}},
url = {https://doi.org/10.1007/s11390-017-1783-2},
volume = {32},
year = {2017}
}
@article{10.1007/s10664-017-9588-z,
author = {Alesio, Leon MoonenThomas RolfsnesDave BinkleyStefano Di},
doi = {10.1007/s10664-017-9588-z},
journal = {Empirical Software Engineering},
number = {4},
title = {{What are the effects of history length and age on mining software change impact?}},
url = {http://link.springer.com/article/10.1007/s10664-017-9588-z},
volume = {23},
year = {2018}
}
@article{Jiang2019,
abstract = {In GitHub, integrators inspect submitted code changes, make evaluation decision, and close pull requests. Some pull requests may be reopened for further modification and code review. It remains unknown why some pull requests are reopened, and how they affect software development. In this paper, we conduct a case study to understand reopened pull requests. We collect 100,622 pull requests from 7 popular projects in GitHub. We study the impacts of reopened pull requests on the code review process. We then qualitatively analyze the root reasons that lead to reopening pull requests. Finally, we examine the characteristics of pull requests caused by various reasons. Our main observations are: 1) Reopened pull requests have lower acceptance rates, more comments, and longer evaluation time than non-reopened pull requests. 2) Several key reasons that lead to reopened pull request are identified such as bugs, change minds, insufficient tests, incompatible version, tests fails, and so on. 3) Reopened pull requests in different categories have various acceptance rates, comment amounts, and evaluation time. Reopened pull requests in the category rebase and change branch has the largest number of comments and the longest evaluation time. These findings provide insights to decrease reopened pull requests, develop a variety of assistant tools, and reduce the maintenance cost of open source projects.},
author = {Jiang, J and Mohamed, A and Zhang, L},
doi = {10.1109/ACCESS.2019.2928566},
issn = {2169-3536 VO - 7},
journal = {IEEE Access},
keywords = {Computer bugs,Data collection,GitHub,Laboratories,Licenses,Rails,Reopened pull requests,Software,Tools,category rebase,code review,inspection,nonreopened pull requests,open source projects,public domain software,reopened pull request,software quality},
pages = {102751--102761},
title = {{What are the Characteristics of Reopened Pull Requests? A Case Study on Open Source Projects in GitHub}},
volume = {7},
year = {2019}
}
@inproceedings{9054834,
abstract = {GitHub facilitates software development practices that encourage collaboration and communication. Part of GitHub's model includes forking, which enables users to make changes on a copy of the base repository. The process of forking opens avenues of communication between the users from the base repository and the users from the forked repositories. Since forking on GitHub is a common mechanism for initiating repositories, we are interested in how communication between a repository and its forks (forming a software family) relates to stars. In this paper, we study communications within 385 software families comprised of 13,431 software repositories. We find that the fork depth, the number of users who have contributed to multiple repositories in the same family, the number of followers from outside the family, familial pull requests, and reported issues share a statistically significant relationship with repository stars. Due to the importance of issues and pull requests, we identify and compare common topics in issues and pull requests from inside the repository (via branching) and within the family (via forking). Our results offer insights into the importance of communication within a software family, and how this leads to higher individual repository star counts.},
author = {Brisson, S and Noei, E and Lyons, K},
booktitle = {2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER48275.2020.9054834},
issn = {1534-5351},
keywords = {data mining;public domain software;software engineering;software families;software repositories;fork depth;pull requests;repository stars;forking;GitHub software repositories;software development practices;Empirical study;Open source software;Data mining;Software maintenance;Software family},
pages = {59--69},
title = {{We Are Family: Analyzing Communication in GitHub Software Repositories and Their Forks}},
year = {2020}
}
@article{arXiv:1912.08722,
abstract = {Abstract: The Age-of-Information (AoI) has recently been proposed as an important metric for investigating the timeliness performance in information-update systems. In this paper, we study the AoI minimization problem under a new Pull model with replication schemes, where a user proactively sends a replicated request to multiple servers to "pull" the information of interest. Interestingly, we find that under this new Pull model, replication schemes capture a novel tradeoff between different values of the AoI across the servers (due to the random updating processes) and different response times across the servers, which can be exploited to minimize the expected AoI at the user's side. Specifically, assuming Poisson updating process for the servers and exponentially distributed response time, we derive a closed-form formula for computing the expected AoI and obtain the optimal number of responses to wait for to minimize the expected AoI. Then, we extend our analysis to the setting where the user aims to maximize the AoI-based utility, which represents the user's satisfaction level with respect to freshness of the received information. Furthermore, we consider a more realistic scenario where the user has no prior knowledge of the system. In this case, we reformulate the utility maximization problem as a stochastic Multi-Armed Bandit problem with side observations and leverage a special linear structure of side observations to design learning algorithms with improved performance guarantees. Finally, we conduct extensive simulations to elucidate our theoretical results and compare the performance of different algorithms. Our findings reveal that under the Pull model, waiting does not necessarily lead to aging; waiting wisely can significantly reduce the AoI and improve the AoI-based utility in most scenarios. △ Less},
author = {{Authors: Fengjiao Li Yu Sang}, Zhongdong Liu Bin Li Huasen Wu Bo Ji},
journal = {arXiv preprint arXiv:1912.08722},
title = {{Waiting but not Aging: Optimizing Information Freshness Under the Pull Model}},
year = {2020}
}
@article{10.1007/s10664-020-09854-3,
author = {Matsumoto, Rungroj MaipraditChristoph TreudeHideaki HataKenichi},
doi = {10.1007/s10664-020-09854-3},
journal = {Empirical Software Engineering},
title = {{Wait for it: identifying “On-Hold” self-admitted technical debt}},
url = {http://link.springer.com/article/10.1007/s10664-020-09854-3},
year = {2020}
}
@inproceedings{10.1145/2950290.2983929,
abstract = { One of the tasks of reviewers is to verify that code modifications are well tested. However, current tools offer little support in understanding precisely how changes to the code relate to changes to the tests. In particular, it is hard to see whether (modified) test code covers the changed code. To mitigate this problem, we developed Operias, a tool that provides a combined visualization of fine-grained source code differences and coverage impact. Operias works both as a stand-alone tool on specific project versions and as a service hooked to GitHub. In the latter case, it provides automated reports for each new pull request, which reviewers can use to assess the code contribution. Operias works for any Java project that works with maven and its standard Cobertura coverage plugin. We present how Operias could be used to identify test-related problems in real-world pull requests. Operias is open source and available on GitHub with a demo video: https://github.com/SERG-Delft/operias },
address = {New York, NY, USA},
author = {Oosterwaal, Sebastiaan and van Deursen, Arie and Coelho, Roberta and Sawant, Anand Ashok and Bacchelli, Alberto},
booktitle = {Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering},
doi = {10.1145/2950290.2983929},
isbn = {9781450342186},
keywords = { code review, software testing,software evolution},
pages = {1038--1041},
publisher = {Association for Computing Machinery},
series = {FSE 2016},
title = {{Visualizing Code and Coverage Changes for Code Review}},
url = {https://doi.org/10.1145/2950290.2983929},
year = {2016}
}
@inproceedings{DBLP:conf/dasfaa/LuMYWB17,
author = {Lu, Yao and Mao, Xinjun and Yin, Gang and Wang, Tao and Bai, Yu},
booktitle = {Database Systems for Advanced Applications - {\{}DASFAA{\}} 2017 International Workshops: BDMS, BDQM, SeCoP, and DMMOOC, Suzhou, China, March 27-30, 2017, Proceedings},
doi = {10.1007/978-3-319-55705-2_32},
editor = {Bao, Zhifeng and Trajcevski, Goce and Chang, Lijun and Hua, Wen},
pages = {399--410},
publisher = {Springer},
series = {Lecture Notes in Computer Science},
title = {{Using Pull-Based Collaborative Development Model in Software Engineering Courses: {\{}A{\}} Case Study}},
url = {https://doi.org/10.1007/978-3-319-55705-2{\_}32},
volume = {10179},
year = {2017}
}
@inproceedings{10.1145/3287324.3293787,
abstract = {Rising enrollments make it difficult for instructors and teaching assistants to give adequate feedback on each student's work. In our software engineering course, we have 50-120 students each semester. Our course projects require students to submit GitHub pull requests as deliverables for their open-source software (OSS) projects. We have set up a static code analyzer and a continuous integration service on GitHub to help students check code style and functionality. However, these tools cannot enforce system-specific customized guidelines and do not explicitly display detailed information. In this study, we discuss how we bypass the limitations of existing tools by implementing three Internet bots. The Expertiza Bot can help detect violations of more than 35 system-specific guidelines. The Travis CI Bot can explicitly display instant test execution results on the GitHub pull-request page. The Code Climate Bot can insert pull-request comments to remind students to fix issues detected by the static code analyzer. These bots are either open source or free for OSS projects, and can be easily integrated with GitHub repositories. Our survey results show that more than 70{\%} of students think the advice given by the bots is useful. We tallied the amount of feedback given by the bots and the teaching staff for each GitHub pull request. Results show that bots can provide significantly more feedback (six times more on average) than teaching staff. Bots can also offer more timely feedback than teaching staff and help student contributions avoid more than 33{\%} system-specific guideline violations.},
address = {New York, NY, USA},
author = {Hu, Zhewei and Gehringer, Edward},
booktitle = {Proceedings of the 50th ACM Technical Symposium on Computer Science Education},
doi = {10.1145/3287324.3293787},
isbn = {9781450358903},
keywords = { expertiza, internet bots, open-source curriculum, software engineering,open-source software},
pages = {1262--1263},
publisher = {Association for Computing Machinery},
series = {SIGCSE '19},
title = {{Use Bots to Improve GitHub Pull-Request Feedback}},
url = {https://doi.org/10.1145/3287324.3293787},
year = {2019}
}
@article{8360943,
abstract = {Continuous Integration (CI) is a popular practice where software systems are automatically compiled and tested as changes appear in the version control system of a project. Like other software artifacts, CI specifications require maintenance effort. Although there are several service providers like TRAVIS CI offering various CI features, it is unclear which features are being (mis)used. In this paper, we present a study of feature use and misuse in 9,312 open source systems that use TRAVIS CI. Analysis of the features that are adopted by projects reveals that explicit deployment code is rare-48.16 percent of the studied TRAVIS CI specification code is instead associated with configuring job processing nodes. To analyze feature misuse, we propose HANSEL-an anti-pattern detection tool for TRAVIS CI specifications. We define four anti-patterns and HANSEL detects anti-patterns in the TRAVIS CI specifications of 894 projects in the corpus (9.60 percent), and achieves a recall of 82.76 percent in a sample of 100 projects. Furthermore, we propose GRETEL-an anti-pattern removal tool for TRAVIS CI specifications, which can remove 69.60 percent of the most frequently occurring antipattern automatically. Using GRETEL, we have produced 36 accepted pull requests that remove TRAVIS CI anti-patterns automatically.},
author = {Gallaba, K and McIntosh, S},
doi = {10.1109/TSE.2018.2838131},
issn = {1939-3520},
journal = {IEEE Transactions on Software Engineering},
keywords = {object-oriented programming;program testing;software development management;software maintenance;software metrics;software performance evaluation;software quality;continuous Integration features;software systems;version control system;CI features;studied TRAVIS CI specification code;anti-pattern detection tool;CI anti-patterns;open source systems;efficiency 48.16 percent;efficiency 9.6 percent;efficiency 69.6 percent;Object oriented programming;Software development management;Software maintenance;Software quality;Software performance;Continuous integration;anti-patterns;mining software repositories},
number = {1},
pages = {33--50},
title = {{Use and Misuse of Continuous Integration Features: An Empirical Study of Projects That (Mis)Use Travis CI}},
volume = {46},
year = {2020}
}
@article{10.1007/s10664-018-9650-5,
author = {Diehl, Sebastian BaltesStephan},
doi = {10.1007/s10664-018-9650-5},
journal = {Empirical Software Engineering},
number = {3},
title = {{Usage and attribution of Stack Overflow code snippets in GitHub projects}},
url = {http://link.springer.com/article/10.1007/s10664-018-9650-5},
volume = {24},
year = {2019}
}
@inproceedings{Huq2019,
abstract = {Developer emotion or sentiment in a software development environment has the potential to affect performance, and consequently, the software itself. Sentiment analysis, conducted to analyze online collaborative artifacts, can derive effects of developer sentiment. This study aims to understand how developer sentiment is related to bugs, by analyzing the difference of sentiment between regular and Fix-Inducing Changes (FIC) - changes to code that introduce bugs in the system. To do so, sentiment is extracted from Pull Requests of 6 well known GitHub repositories, which contain both code and contributor discussion. Sentiment is calculated using a tool specializing in the software engineering domain: SentiStrength-SE. Next, FICs are detected from Commits by filtering the ones that fix bugs and tracking the origin of the code these remove. Commits are categorized based on FICs and assigned separate sentiment scores (-4 to +4) based on different preceding artifacts - Commits, Comments and Reviews from Pull Requests. The statistical result shows that FICs, compared to regular Commits, contain more positive Comments and Reviews. Commits that precede an FIC have more negative messages. Similarly, all the Pull Request artifacts combined are more negative for FICs than regular Commits.},
author = {Huq, S F and Sadiq, A Z and Sakib, K},
booktitle = {2019 26th Asia-Pacific Software Engineering Conference (APSEC)},
doi = {10.1109/APSEC48747.2019.00075},
isbn = {2640-0715 VO -},
keywords = {FIC,GitHub pull requests,GitHub repositories,SentiStrength-SE,Software Engineering, Sentiment Analysis, Data Min,bugs,developer emotion,developer sentiment,fix-inducing changes,preceding artifacts,program debugging,pull request artifacts,regular commits,sentiment analysis,separate sentiment scores,social networking (online),software development environment,software quality},
pages = {514--521},
title = {{Understanding the Effect of Developer Sentiment on Fix-Inducing Changes: An Exploratory Study on GitHub Pull Requests}},
year = {2019}
}
@article{10.1007/s10664-017-9586-1,
author = {Cavalcanti, Paola AcciolyPaulo BorbaGuilherme},
doi = {10.1007/s10664-017-9586-1},
journal = {Empirical Software Engineering},
number = {4},
title = {{Understanding semi-structured merge conflict characteristics in open-source Java projects}},
url = {http://link.springer.com/article/10.1007/s10664-017-9586-1},
volume = {23},
year = {2018}
}
@inproceedings{8944878,
abstract = {GitHub is a web-based collaborative platform for software developers with around 28 million users and 57 million public repositories which promote social coding. GitHub is an evolving network with the developments in the projects and repositories. The underlying working principle of GitHub is based on the events occurring in a time-based manner. The number of events of a repository is proportional to its popularity. In this proposed work, we perform trend prediction on GitHub. The trend prediction is categorised into three tasks, repository trend prediction, language trend prediction and domain trend prediction respectively. Using most relevant and recurring events, such as Create, Fork, Pullrequest, Push and issue, a multivariate time series is constructed. Trends are predicted with time series forecasting using Long Short Term Memory(LSTM) model. The trend prediction results compare the repositories, languages and domains and help in identifying the trending ones. GitHub insights are taken to facilitate social coding and in selecting the relevant languages and domains for the upcoming projects.},
author = {Varuna, T V and Mohan, A},
booktitle = {2019 10th International Conference on Computing, Communication and Networking Technologies (ICCCNT)},
doi = {10.1109/ICCCNT45670.2019.8944878},
keywords = {forecasting theory;groupware;Internet;public domain software;recurrent neural nets;software engineering;time series;relevant recurring events;domain trend prediction;language trend prediction;repository trend prediction;working principle;software developers;web-based collaborative platform;time series analysis;social coding;GitHub insights;trend prediction results;time series forecasting;multivariate time series;Time series analysis;Market research;Predictive models;Logic gates;Data mining;Recurrent neural networks;Collaboration;GitHub;time series analysis;Long short term memory(LSTM);trend prediction;forecasting},
pages = {1--7},
title = {{Trend Prediction of GitHub using Time Series Analysis}},
year = {2019}
}
@phdthesis{rose2017towards,
abstract = {In Open Source Software (OSS), most of the contributions come from the user community than the project's core developers. Pull-based development model has become a recent trend in distributed projects development where contributions are submitted as pull requests},
author = {Rose, Tresa},
school = {Carleton University},
title = {{Towards Understanding What Factors Affect Pull Request Merges}},
url = {https://curve.carleton.ca/4d6605dd-eed2-4b0f-b1e1-1b92f6dea244},
year = {2017}
}
@inproceedings{10.1145/3385032.3385052,
abstract = {The vast growth in usage of GitHub by developers to host their projects has led to extensive forking and open source contributions. These contributions occur in the form of issues that report bugs or pull requests to either fix bugs or add new features to the project. On the other hand, massive increase in the number of issues reported by developers and users is a major challenge for integrators, as the number of concurrent issues to be handled is much higher than the number of core contributors. While there exists prior work on prioritizing pull requests, in this paper we make an attempt towards prioritizing issues using machine learning techniques. We present the Issue Prioritizer, a tool to prioritize issues based on three criteria: issue lifetime, issue hotness and category of the issue. We see this work as an initial step towards supporting developers to handle large volumes of issues in projects.},
address = {New York, NY, USA},
author = {Dhasade, Akash Balasaheb and Venigalla, Akhila Sri Manasa and Chimalakonda, Sridhar},
booktitle = {Proceedings of the 13th Innovations in Software Engineering Conference on Formerly Known as India Software Engineering Conference},
doi = {10.1145/3385032.3385052},
isbn = {9781450375948},
keywords = { Automatic Issue Prioritisation, Dynamic Tracking, Multiple Concurrent Issues, Priority Ranking,GitHub Issues},
publisher = {Association for Computing Machinery},
series = {ISEC 2020},
title = {{Towards Prioritizing GitHub Issues}},
url = {https://doi.org/10.1145/3385032.3385052},
year = {2020}
}
@article{fazayeli2019towards,
abstract = {In recent years continuous integration has become an important practice for pull-based software development. It helps developers make contributions flexibly to an isolated copy of the project's repository, create a pull request that represent such changes, and submit it to},
author = {Fazayeli, Hassan and Syed-Mohamad, Sharifah Mashita and Akhir, Nur Shazwani Md},
journal = {Procedia Computer Science},
pages = {585--592},
publisher = {Elsevier},
title = {{Towards Auto-labelling Issue Reports for Pull-Based Software Development using Text Mining Approach}},
url = {https://www.sciencedirect.com/science/article/pii/S187705091931871X},
volume = {161},
year = {2019}
}
@inproceedings{10.1109/BotSE.2019.00015,
abstract = {Continuous refactoring is necessary to maintain source code quality and to cope with technical debt. Since manual refactoring is inefficient and error-prone, various solutions for automated refactoring have been proposed in the past. However, empirical studies have shown that these solutions are not widely accepted by software developers and most refactorings are still performed manually. For example, developers reported that refactoring tools should support functionality for reviewing changes. They also criticized that introducing such tools would require substantial effort for configuration and integration into the current development environment.In this paper, we present our work towards the Refactoring-Bot, an autonomous bot that integrates into the team like a human developer via the existing version control platform. The bot automatically performs refactorings to resolve code smells and presents the changes to a developer for asynchronous review via pull requests. This way, developers are not interrupted in their workflow and can review the changes at any time with familiar tools. Proposed refactorings can then be integrated into the code base via the push of a button. We elaborate on our vision, discuss design decisions, describe the current state of development, and give an outlook on planned development and research activities.},
author = {Wyrich, Marvin and Bogner, Justus},
booktitle = {Proceedings of the 1st International Workshop on Bots in Software Engineering},
doi = {10.1109/BotSE.2019.00015},
keywords = { code smells, maintainability, refactoring, software evolution, software quality improvement,bot},
pages = {24--28},
publisher = {IEEE Press},
series = {BotSE '19},
title = {{Towards an Autonomous Bot for Automatic Source Code Refactoring}},
url = {https://doi.org/10.1109/BotSE.2019.00015},
year = {2019}
}
@article{arXiv:1710.10421,
abstract = {Abstract: Pull Request (PR) is the main method for code contributions from the external contributors in GitHub. PR review is an essential part of open source software developments to maintain the quality of software. Matching a new PR for an appropriate integrator will make the PR reviewing more effective. However, PR and integrator matching are now organized manually in GitHub. To make this process more efficient, we propose a Topic-based Integrator Matching Algorithm (TIMA) to predict highly relevant collaborators(the core developers) as the integrator to incoming PRs . TIMA takes full advantage of the textual semantics of PRs. To define the relationships between topics and collaborators, TIMA builds a relation matrix about topic and collaborators. According to the relevance between topics and collaborators, TIMA matches the suitable collaborators as the PR integrator. △ Less},
author = {Liao, Z and Li, Y and He, D and Wu, J and Zhang, Y and Fan, X and {Authors: Zhifang Liao Yanbing Li}, Jinsong Wu Dayu He Xiaoping Fan Yan Zhang},
doi = {10.1109/GLOCOM.2017.8254426},
isbn = { VO -},
journal = {arXiv preprint arXiv:1710.10421},
keywords = {,Algorithm design and analysis,Big Data,GitHub,Merging,PR integrator,PR review,PR textual semantics,Probability,Social network services,Software,TIMA,Topic-based Integrator Matching Algorithm,code contributions,integrated software,open source software developments,public domain software,pull request,software quality,source code (software)},
pages = {1--6},
title = {{Topic-Based Integrator Matching for Pull Request}},
year = {2017}
}
@inproceedings{10.1109/ICSE.2019.00060,
abstract = {Quality assurance automation is essential in modern software development. In practice, this automation is supported by a multitude of tools that fit different needs and require developers to make decisions about which tool to choose in a given context. Data and analytics of the pros and cons can inform these decisions. Yet, in most cases, there is a dearth of empirical evidence on the effectiveness of existing practices and tool choices.We propose a general methodology to model the time-dependent effect of automation tool choice on four outcomes of interest: prevalence of issues, code churn, number of pull requests, and number of contributors, all with a multitude of controls. On a large data set of npm JavaScript projects, we extract the adoption events for popular tools in three task classes: linters, dependency managers, and coverage reporters. Using mixed methods approaches, we study the reasons for the adoptions and compare the adoption effects within each class, and sequential tool adoptions across classes. We find that some tools within each group are associated with more beneficial outcomes than others, providing an empirical perspective for the benefits of each. We also find that the order in which some tools are implemented is associated with varying outcomes.},
author = {Kavaler, David and Trockman, Asher and Vasilescu, Bogdan and Filkov, Vladimir},
booktitle = {Proceedings of the 41st International Conference on Software Engineering},
doi = {10.1109/ICSE.2019.00060},
pages = {476--487},
publisher = {IEEE Press},
series = {ICSE '19},
title = {{Tool Choice Matters: JavaScript Quality Assurance Tools and Usage Outcomes in GitHub Projects}},
url = {https://doi.org/10.1109/ICSE.2019.00060},
year = {2019}
}
@inproceedings{9014249,
abstract = {Code review is an important way to improve software quality and ensure project security. Pull Request (PR), as an important method of collaborative code modification in GitHub open source software community platform, is very important to find a suitable code reviewer to improve code modification efficiency for Pull Request submitted by code modifiers. In order to solve this problem, we have proposed a review recommendation algorithm based on Pull Request topic model and reviewer's influence. This algorithm has not only extracted the topic information of PR through Latent Dirichlet Allocation (LDA) method, but also analyzed the professional knowledge influence of reviewers through influence network. What{\^{a}}€™s more, it has combined the topic information of reviewers to find the appropriate PR reviewers. The experimental results based on GitHub show that the algorithm is more efficient, which can effectively reduce the time of code review and improve the recommendation accuracy.},
author = {Liao, Z and Wu, Z and Wu, J and Zhang, Y and Liu, J and Long, J},
booktitle = {2019 IEEE Global Communications Conference (GLOBECOM)},
doi = {10.1109/GLOBECOM38437.2019.9014249},
issn = {2576-6813},
pages = {1--6},
title = {{TIRR: A Code Reviewer Recommendation Algorithm with Topic Model and Reviewer Influence}},
year = {2019}
}
@inproceedings{10.1145/3195836.3195841,
abstract = {As a software system is iteratively developed, software developers engage in many discussions, often through written forms. Some of these discussions occur on pull requests and include information about the design of the system to which the code in the pull request is being contributed. Although previous work has shown that design is discussed in forums like pull requests, little is known about the form and content of the discussion about design.In this paper, we report on an in-depth analysis of three pull requests to better understand the form and content of design information in pull request discussions to enable the development of tools to help humans access this information.},
address = {New York, NY, USA},
author = {Viviani, Giovanni and Janik-Jones, Calahan and Famelis, Michalis and Murphy, Gail C},
booktitle = {Proceedings of the 11th International Workshop on Cooperative and Human Aspects of Software Engineering},
doi = {10.1145/3195836.3195841},
isbn = {9781450357258},
pages = {104--107},
publisher = {Association for Computing Machinery},
series = {CHASE '18},
title = {{The Structure of Software Design Discussions}},
url = {https://doi.org/10.1145/3195836.3195841},
year = {2018}
}
@inproceedings{9054818,
abstract = {The adoption of Continuous Integration (CI) has been shown multiple benefits for software engineering practices related to build, test and dependency management. However, the impact of CI on the social aspects of software development has been overlooked so far. Specifically, we focus on studying the impact of CI on a paradigmatic socio-technical activity within the software engineering domain, namely code reviews. Indeed, one might expect that the introduction of CI allows reviewers to focus on more challenging aspects of software quality that could not be assessed using CI. To assess validity of this expectation we conduct an exploratory study of code reviews in 685 GitHub projects that have adopted Travis-CI, the most popular CI-service on GitHub. We observe that with the introduction of CI, pull requests are being discussed less. On average CI saves up to one review comment per pull request. This decrease in amount of discussion, however, cannot be explained by the decrease in the number of updates of the pull requests. This means that in presence of CI developers perform the same amount of work by communicating less, giving rise to the idea of CI as a silent helper.},
author = {Cassee, N and Vasilescu, B and Serebrenik, A},
booktitle = {2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER48275.2020.9054818},
issn = {1534-5351},
keywords = {social aspects of automation;software quality;silent helper;continuous integration;code reviews;software engineering practices;software development;Travis-CI;pull request;CI developers;CI-service;dependency management;social aspects;paradigmatic socio-technical activity;software quality;GitHub projects},
pages = {423--434},
title = {{The Silent Helper: The Impact of Continuous Integration on Code Reviews}},
year = {2020}
}
@inproceedings{10.1145/2597073.2597074,
abstract = { With over 10 million git repositories, GitHub is becoming one of the most important source of software artifacts on the Internet. Researchers are starting to mine the information stored in GitHub's event logs, trying to understand how its users employ the site to collaborate on software. However, so far there have been no studies describing the quality and properties of the data available from GitHub. We document the results of an empirical study aimed at understanding the characteristics of the repositories in GitHub and how users take advantage of GitHub's main features---namely commits, pull requests, and issues. Our results indicate that, while GitHub is a rich source of data on software development, mining GitHub for research purposes should take various potential perils into consideration. We show, for example, that the majority of the projects are personal and inactive; that GitHub is also being used for free storage and as a Web hosting service; and that almost 40{\%} of all pull requests do not appear as merged, even though they were. We provide a set of recommendations for software engineering researchers on how to approach the data in GitHub. },
address = {New York, NY, USA},
author = {Kalliamvakou, Eirini and Gousios, Georgios and Blincoe, Kelly and Singer, Leif and German, Daniel M and Damian, Daniela},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
doi = {10.1145/2597073.2597074},
isbn = {9781450328630},
keywords = { bias, code reviews, git, github,Mining software repositories},
pages = {92--101},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{The Promises and Perils of Mining GitHub}},
url = {https://doi.org/10.1145/2597073.2597074},
year = {2014}
}
@article{10.1145/3274451,
abstract = {Leveraging the pull request model of social coding platforms, Open Source Software (OSS) integrators review developers' contributions, checking aspects like license, code quality, and testability. Some projects use bots to automate predefined, sometimes repetitive tasks, thereby assisting integrators' and contributors' work. Our research investigates the usage and impact of such bots. We sampled 351 popular projects from GitHub and found that 93 (26{\%}) use bots. We classified the bots, collected metrics from before and after bot adoption, and surveyed 228 developers and integrators. Our results indicate that bots perform numerous tasks. Although integrators reported that bots are useful for maintenance tasks, we did not find a consistent, statistically significant difference between before and after bot adoption across the analyzed projects in terms of number of comments, commits, changed files, and time to close pull requests. Our survey respondents deem the current bots as not smart enough and provided insights into the bots' relevance for specific tasks, challenges, and potential new features. We discuss some of the raised suggestions and challenges in light of the literature in order to help GitHub bot designers reuse and test ideas and technologies already investigated in other contexts.},
address = {New York, NY, USA},
author = {Wessel, Mairieli and de Souza, Bruno Mendes and Steinmacher, Igor and Wiese, Igor S and Polato, Ivanilton and Chaves, Ana Paula and Gerosa, Marco A},
doi = {10.1145/3274451},
journal = {Proc. ACM Hum.-Comput. Interact.},
keywords = { automated agents, bots, chatbots, open source software, pull request,pull-based model},
number = {CSCW},
publisher = {Association for Computing Machinery},
title = {{The Power of Bots: Characterizing and Understanding Bots in OSS Projects}},
url = {https://doi.org/10.1145/3274451},
volume = {2},
year = {2018}
}
@article{10.1007/s10664-018-9674-x,
author = {Dig, Nicholas NelsonCaius BrindescuShane McKeeAnita SarmaDanny},
doi = {10.1007/s10664-018-9674-x},
journal = {Empirical Software Engineering},
number = {5},
title = {{The life-cycle of merge conflicts: processes, barriers, and strategies}},
url = {http://link.springer.com/article/10.1007/s10664-018-9674-x},
volume = {24},
year = {2019}
}
@article{10.1007/s10664-018-9646-1,
author = {Matsumoto, Shade RuangwanPatanamon ThongtanunamAkinori IharaKenichi},
doi = {10.1007/s10664-018-9646-1},
journal = {Empirical Software Engineering},
number = {2},
title = {{The impact of human factors on the participation decision of reviewers in modern code review}},
url = {http://link.springer.com/article/10.1007/s10664-018-9646-1},
volume = {24},
year = {2019}
}
@article{arXiv:1709.10324,
abstract = {Abstract: Background: Understanding the condition of OSS projects is important to analyze features and predict the future of projects. In the field of demography and economics, health and wealth are considered to understand the condition of a country. Aim: In this paper, we apply this framework to OSS projects to understand the communities and the evolution of OSS projects from the perspectives of health and wealth. Method: We define two measures of Workforce (WF) and Gross Product Pull Requests (GPPR). We analyze OSS projects in GitHub and investigate three typical cases. Results: We find that wealthy projects attract and rely on the casual workforce. Less wealthy projects may require additional efforts from their more experienced contributors. Conclusions: This paper presents an approach to assess the relationship between health and wealth of OSS projects. An interactive demo of our analysis is available at goo.gl/Ig6NTR. △ Less},
author = {{Authors: Saya Onoue Raula Gaikovina Kula}, Hideaki Hata Kenichi Matsumoto},
journal = {arXiv preprint arXiv:1709.10324},
title = {{The Health and Wealth of OSS Projects: Evidence from Community Activities and Product Evolution}},
year = {2017}
}
@article{arXiv:1807.02037,
abstract = {Abstract: While accelerators such as GPUs have limited memory, deep neural networks are becoming larger and will not fit with the memory limitation of accelerators for training. We propose an approach to tackle this problem by rewriting the computational graph of a neural network, in which swap-out and swap-in operations are inserted to temporarily store intermediate results on CPU memory. In particular, we first revise the concept of a computational graph by defining a concrete semantics for variables in a graph. We then formally show how to derive swap-out and swap-in operations from an existing graph and present rules to optimize the graph. To realize our approach, we developed a module in TensorFlow, named TFLMS. TFLMS is published as a pull request in the TensorFlow repository for contributing to the TensorFlow community. With TFLMS, we were able to train ResNet-50 and 3DUnet with 4.7x and 2x larger batch size, respectively. In particular, we were able to train 3DUNet using images of size of 1923 for image segmentation, which, without TFLMS, had been done only by dividing the images to smaller images, which affects the accuracy. △ Less},
author = {{Authors: Tung D. Le Haruki Imai}, Yasushi Negishi Kiyokuni Kawachiya},
journal = {arXiv preprint arXiv:1807.02037},
title = {{TFLMS: Large Model Support in TensorFlow by Graph Rewriting}},
year = {2019}
}
@article{8839858,
abstract = {Much research has investigated the common reasons for build breakages. However, prior research has paid little attention to builds that may break due to reasons that are unlikely to be related to development activities. For example, Continuous Integration(CI) builds may break due to timeout or connection errors while generating the build. Such kinds of build breakages potentially introduce noises to build breakage data. Not considering such noises may lead to misleading results when studying CI builds. In this paper, we propose three criteria to identify build breakages that can potentially introduce noises to build breakage data. We apply these criteria to a dataset of 350,246 builds from153 GitHub projects that are linked with Travis CI. Our results reveal that 33{\%} of the build breakages are due to environmental factors (e.g., errors in CI servers), 29{\%} are due to (unfixed) errors in previous builds, and 9{\%} are due to build jobs that were later deemed by developers as noisy (there is an overlap of 17{\%} between these three types of breakages). We measure the impact of noises in build breakage data on modeling build breakages. We observe that models that use uncleaned build breakage data can lead to misleading associations between build breakages and development activities (e.g., the role of developer). However, such associations could not be observed after eliminating noisy build breakages. Moreover, we replicate a prior study that investigates the association between build breakages and development activities using data from 14 GitHub projects. We observe that some observations reported by the prior study (e.g., pull requests cause more breakages) do not hold after eliminating the noises from build breakage data.},
author = {Ghaleb, T A and {Alencar da Costa}, D and Zou, Y and Hassan, A E},
doi = {10.1109/TSE.2019.2941880},
issn = {1939-3520},
journal = {IEEE Transactions on Software Engineering},
keywords = {Noise measurement;Data models;Software;Environmental factors;Servers;Indexes;Continuous Integration;CI build breakages;Noisy data;Mining software repositories;Empirical software engineering},
pages = {1},
title = {{Studying the Impact of Noises in Build Breakage Data}},
year = {2019}
}
@inproceedings{10.1145/3196398.3196421,
abstract = {Continuous Integration (CI) is a software development practice that leads developers to integrate their work more frequently. Software projects have broadly adopted CI to ship new releases more frequently and to improve code integration. The adoption of CI is motivated by the allure of delivering new functionalities more quickly. However, there is little empirical evidence to support such a claim. Through the analysis of 162,653 pull requests (PRs) of 87 GitHub projects that are implemented in 5 different programming languages, we empirically investigate the impact of adopting CI on the time to deliver merged PRs. Surprisingly, only 51.3{\%} of the projects deliver merged PRs more quickly after adopting CI. We also observe that the large increase of PR submissions after CI is a key reason as to why projects deliver PRs more slowly after adopting CI. To investigate the factors that are related to the time-to-delivery of merged PRs, we train regression models that obtain sound median R-squares of 0.64-0.67. Finally, a deeper analysis of our models indicates that, before the adoption of CI, the integration-load of the development team, i.e., the number of submitted PRs competing for being merged, is the most impactful metric on the time to deliver merged PRs before CI. Our models also reveal that PRs that are merged more recently in a release cycle experience a slower delivery time.},
address = {New York, NY, USA},
author = {Bernardo, Jo{\~{a}}o Helis and da Costa, Daniel Alencar and Kulesza, Uir{\'{a}}},
booktitle = {Proceedings of the 15th International Conference on Mining Software Repositories},
doi = {10.1145/3196398.3196421},
isbn = {9781450357166},
keywords = { continuous integration, delivery time, pull request, pull-based development,delivery delay},
pages = {131--141},
publisher = {Association for Computing Machinery},
series = {MSR '18},
title = {{Studying the Impact of Adopting Continuous Integration on the Delivery Time of Pull Requests}},
url = {https://doi.org/10.1145/3196398.3196421},
year = {2018}
}
@article{DBLP:journals/peerj-cs/GuoL19,
author = {Guo, Yunfang and Leitner, Philipp},
doi = {10.7717/peerj-cs.245},
journal = {PeerJ Comput. Sci.},
pages = {e245},
title = {{Studying the impact of {\{}CI{\}} on pull request delivery time in open source projects - a conceptual replication}},
url = {https://doi.org/10.7717/peerj-cs.245},
volume = {5},
year = {2019}
}
@inproceedings{Kononenko2018,
abstract = {Pull-based development has become a popular choice for developing distributed projects, such as those hosted on GitHub. In this model, contributions are pulled from forked repositories, modified, and then later merged back into the main repository. In this work, we report on two empirical studies that investigate pull request (PR) merges of Active Merchant, a commercial project developed by Shopify Inc. In the first study, we apply data mining techniques on the project's GitHub repository to explore the nature of merges, and we conduct a manual inspection of pull requests; we also investigate what factors contribute to PR merge time and outcome. In the second study, we perform a qualitative analysis of the results of a survey of developers who contributed to Active Merchant. The study addresses the topic of PR review quality and developers' perception of it. The results provide insights into how these developers perform pull request merges, and what factors they find contribute to how they review and merge pull requests.},
author = {Kononenko, O and Rose, T and Baysal, O and Godfrey, M and Theisen, D and de Water, B},
booktitle = {2018 IEEE/ACM 40th International Conference on Software Engineering: Software Engineering in Practice Track (ICSE-SEIP)},
isbn = { VO -},
keywords = {Computer science,Data mining,Electronic mail,GitHub repository,Libraries,Logic gates,PR,Pull request merges,Shopify's Active Merchant,Software,Software engineering,commercial project,data mining,data mining techniques,distributed projects,forked repositories,industrial case study,pull request merges,pull requests,qualitative analysis,review quality,software maintenance,software quality,survey},
pages = {124--133},
title = {{Studying Pull Request Merges: A Case Study of Shopify's Active Merchant}},
year = {2018}
}
@inproceedings{10.1109/BotSE.2019.00021,
abstract = {Bots have been proposed as a way to encourage developer actions and support software development activities. Many bots make recommendations to users, however humans may find these recommendations ineffective or problematic. In this paper, we argue that while bots can help automate many tasks, ultimately bots still need to find ways to interact with humans and handle all of the associated social and cognitive problems entailed. To illustrate this problem, we performed a small study where we generated 52 pull requests making tool recommendation to developers. As a result, we only convinced two developers to accept the pull request, while receiving several forms of feedback on why the pull request was ineffective. We summarize this feedback and suggest design principles for bot recommendations, including how psychology frameworks, such as nudge theory, can be used to improve human-bot interactions.},
author = {Brown, Chris and Parnin, Chris},
booktitle = {Proceedings of the 1st International Workshop on Bots in Software Engineering},
doi = {10.1109/BotSE.2019.00021},
keywords = { developer actions, digital nudge, tool adoption,software engineering},
pages = {54--58},
publisher = {IEEE Press},
series = {BotSE '19},
title = {{Sorry to Bother You: Designing Bots for Effective Recommendations}},
url = {https://doi.org/10.1109/BotSE.2019.00021},
year = {2019}
}
@inproceedings{DBLP:conf/apsec/Syed-MohamadA19,
author = {Syed-Mohamad, Sharifah Mashita and Akhir, Nur Shazwani Md.},
booktitle = {26th Asia-Pacific Software Engineering Conference, {\{}APSEC{\}} 2019, Putrajaya, Malaysia, December 2-5, 2019},
doi = {10.1109/APSEC48747.2019.00011},
pages = {9--14},
publisher = {IEEE},
title = {{SoReady: An Extension of the Test and Defect Coverage-Based Analytics Model for Pull-Based Software Development}},
url = {https://doi.org/10.1109/APSEC48747.2019.00011},
year = {2019}
}
@inproceedings{10.1109/ICSE.2019.00122,
abstract = {(Good) Software documentation provides developers and users with a description of what a software system does, how it operates, and how it should be used. For example, technical documentation (e.g., an API reference guide) aids developers during evolution/maintenance activities, while a user manual explains how users are to interact with a system. Despite its intrinsic value, the creation and the maintenance of documentation is often neglected, negatively impacting its quality and usefulness, ultimately leading to a generally unfavorable take on documentation.Previous studies investigating documentation issues have been based on surveying developers, which naturally leads to a somewhat biased view of problems affecting documentation. We present a large scale empirical study, where we mined, analyzed, and categorized 878 documentation-related artifacts stemming from four different sources, namely mailing lists, Stack Overflow discussions, issue repositories, and pull requests. The result is a detailed taxonomy of documentation issues from which we infer a series of actionable proposals both for researchers and practitioners.},
author = {Aghajani, Emad and Nagy, Csaba and Vega-M{\'{a}}rquez, Olga Lucero and Linares-V{\'{a}}squez, Mario and Moreno, Laura and Bavota, Gabriele and Lanza, Michele},
booktitle = {Proceedings of the 41st International Conference on Software Engineering},
doi = {10.1109/ICSE.2019.00122},
keywords = { empirical study,documentation},
pages = {1199--1210},
publisher = {IEEE Press},
series = {ICSE '19},
title = {{Software Documentation Issues Unveiled}},
url = {https://doi.org/10.1109/ICSE.2019.00122},
year = {2019}
}
@article{10.1007/s11432-015-1024-6,
author = {Yu, Yang ZhangHuaimin WangGang YinTao WangYue},
doi = {10.1007/s11432-015-1024-6},
journal = {Science China Information Sciences},
number = {3},
title = {{Social media in GitHub: the role of @-mention in assisting software development}},
url = {http://link.springer.com/article/10.1007/s11432-015-1024-6},
volume = {60},
year = {2016}
}
@inproceedings{10.1145/2993412.3003384,
abstract = {Software ecosystems evolve through an active community of developers who contribute to projects within the ecosystem. However, development teams change over time, suggesting a potential impact on the evolution of the technical parts of the ecosystem. The impact of such modifications has been studied by previous works, but only temporary changes have been investigated, while the long-term effect of permanent changes has yet to be explored. In this paper, we investigate the evolution of the ecosystem of Ruby on Rails in GitHub in terms of such temporary and permanent changes of the development team. We use three viewpoints of the Rails ecosystem evolution to discuss our preliminary findings: (1) the base project; (2) the forks; and (3) the entire ecosystem containing both base project and forks.},
address = {New York, NY, USA},
author = {Constantinou, Eleni and Mens, Tom},
booktitle = {Proccedings of the 10th European Conference on Software Architecture Workshops},
doi = {10.1145/2993412.3003384},
isbn = {9781450347815},
keywords = { social evolution, software ecosystems,technical evolution},
publisher = {Association for Computing Machinery},
series = {ECSAW '16},
title = {{Social and Technical Evolution of Software Ecosystems: A Case Study of Rails}},
url = {https://doi.org/10.1145/2993412.3003384},
year = {2016}
}
@inproceedings{8730155,
abstract = {Developers may choose to implement a library, despite the existence of similar libraries, considering factors such as computational performance, language or platform dependency, and accuracy. As a result, GitHub is a host to several library projects that have overlaps in the functionalities. These overlaps have been of interest to developers from the perspective of code reuse or preferring one implementation over the other. We present an empirical study to explore the extent and nature of existence of these similarities in the library functions. We have further studied whether the similarity among functions across different libraries and their associated test suites can be leveraged to reveal defects in one another. Applying a natural language processing based approach on the documentations associated with functions, we have extracted matching functions across 12 libraries, available on GitHub, over 2 programming languages and 3 themes. Our empirical evaluation indicates existence of a significant number of similar functions across libraries in same as well as different programming languages where a language can influence the extent of existence of similarities. The test suites from another library can serve as an effective source of defect revealing tests. The study resulted in revealing 72 defects in 12 libraries. Further, we analyzed the source of origination of the defect revealing tests. We deduce that issue reports and pull requests can be beneficial in attaining quality test cases not only to test the libraries in which these issues are reported but also for other libraries that are similar in theme.},
author = {Sondhi, D and Rani, D and Purandare, R},
booktitle = {2019 12th IEEE Conference on Software Testing, Validation and Verification (ICST)},
doi = {10.1109/ICST.2019.00018},
issn = {2159-4848},
keywords = {natural language processing;program testing;programming languages;software libraries;library projects;library functions;natural language processing;defect revealing tests;test suites;programming languages;GitHub;Libraries;Documentation;Data mining;Testing;Training;Python;Natural language processing;libraries;language;similarities;test suites;defect exposure;issue reports},
pages = {79--89},
title = {{Similarities Across Libraries: Making a Case for Leveraging Test Suites}},
year = {2019}
}
@inproceedings{10.1109/BotSE.2019.00018,
abstract = {On GitHub, projects use bots to automate predefined and repetitive tasks related to issues and pull requests. Our research investigates the adoption of the stale bot, which helps maintainers triaging abandoned issues and pull requests. We analyzed the bots' configuration settings and their modifications over time. These settings define the time for tagging issues and pull request as stale and closing them. We collected data from 765 OSS projects hosted on GitHub. Our results indicate that most of the studied projects made no more than three modifications in the configurations file, issues tagged as bug reports are exempt from being considered stale, while the same occurs with pull requests that need some input to be processed.},
author = {Wessel, Mairieli and Steinmacher, Igor and Wiese, Igor and Gerosa, Marco A},
booktitle = {Proceedings of the 1st International Workshop on Bots in Software Engineering},
doi = {10.1109/BotSE.2019.00018},
keywords = { abandoned issues, open source software,bots},
pages = {38--42},
publisher = {IEEE Press},
series = {BotSE '19},
title = {{Should I Stale or Should I Close? An Analysis of a Bot That Closes Abandoned Issues and Pull Requests}},
url = {https://doi.org/10.1109/BotSE.2019.00018},
year = {2019}
}
@inproceedings{10.1145/2597073.2597117,
abstract = { Application security is becoming increasingly prevalent during software and especially web application development. Consequently, countermeasures are continuously being discussed and built into applications, with the goal of reducing the risk that unauthorized code will be able to access, steal, modify, or delete sensitive data. In this paper we gauged the presence and atmosphere surrounding security-related discussions on GitHub, as mined from discussions around commits and pull requests. First, we found that security related discussions account for approximately 10{\%} of all discussions on GitHub. Second, we found that more negative emotions are expressed in security-related discussions than in other discussions. These findings confirm the importance of properly training developers to address security concerns in their applications as well as the need to test applications thoroughly for security vulnerabilities in order to reduce frustration and improve overall project atmosphere. },
address = {New York, NY, USA},
author = {Pletea, Daniel and Vasilescu, Bogdan and Serebrenik, Alexander},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
doi = {10.1145/2597073.2597117},
isbn = {9781450328630},
keywords = { Security, mining challenge, sentiment analysis,GitHub},
pages = {348--351},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{Security and Emotion: Sentiment Analysis of Security Discussions on GitHub}},
url = {https://doi.org/10.1145/2597073.2597117},
year = {2014}
}
@inproceedings{7434293,
abstract = {Vehicular ad hoc network performs crucial function in road safety, detection of traffic accidents and reduction of traffic congestion by disseminating messages among vehicles. The periodic broadcasting is an efficient approach to serve the requests of many vehicles without selecting any route between source and destination. But it degrades the network performance due to hidden node problem and broadcasting storm problem. The present work is an on demand type of unicast pull based approach of data dissemination in vehicular ad hoc network. It disseminates data in the form of response message after receiving any query message from vehicle. The performance of the proposed scheme is evaluated in terms of block of service, loss of query messages due to time out, average required time of sending response messages to the vehicles and throughput.},
author = {Mondal, A and Mitra, S},
booktitle = {2015 IEEE International Conference on Communication, Networks and Satellite (COMNESTAT)},
doi = {10.1109/COMNETSAT.2015.7434293},
keywords = {broadcasting;data communication;telecommunication traffic;vehicular ad hoc networks;secure data dissemination;VANET;pull based approach;vehicular ad hoc network;road safety;traffic accidents detection;traffic congestion reduction;periodic broadcasting;hidden node problem;broadcasting storm problem;unicast pull based approach;Vehicles;Vehicular ad hoc networks;Broadcasting;Unicast;Standards;Databases},
pages = {60--67},
title = {{Secure data dissemination in VANET - a pull based approach}},
year = {2015}
}
@article{10.1007/s11771-018-3812-x,
abstract = {Code review is an important process to reduce code defects and improve software quality. In social coding communities like GitHub, as everyone can submit Pull-Requests, code review plays a more important role than ever before, and the process is quite time-consuming},
author = {Yang, Cheng and Zhang, Xun-hui and Zeng, Ling-bin and Fan, Qiang and Wang, Tao and Yu, Yue and Yin, Gang and Wang, Huai-min and 王怀民, Cheng Yang 杨程Xun-hui Zhang 张迅晖Ling-bin Zeng 曾令斌Qiang Fan 范强Tao Wang 王涛Yue Yu 余跃Gang Yin 尹刚Huai-min Wang},
doi = {10.1007/s11771-018-3812-x},
journal = {Journal of Central South University},
number = {5},
pages = {1129--1143},
publisher = {Springer},
title = {{RevRec: A two-layer reviewer recommendation algorithm in pull-based development model}},
url = {http://link.springer.com/article/10.1007/s11771-018-3812-x https://link.springer.com/article/10.1007/s11771-018-3812-x},
volume = {25},
year = {2018}
}

661
experiment/study-search/papers-2.bib Normal file
View File

@ -0,0 +1,661 @@
@article{DBLP:journals/infsof/YuWYW16,
author = {Yu, Yue and Wang, Huaimin and Yin, Gang and Wang, Tao},
doi = {10.1016/j.infsof.2016.01.004},
journal = {Inf. Softw. Technol.},
pages = {204--218},
title = {{Reviewer recommendation for pull-requests in GitHub: What can we learn from code review and bug assignment?}},
url = {https://doi.org/10.1016/j.infsof.2016.01.004},
volume = {74},
year = {2016}
}
@inproceedings{9033820,
abstract = {Distributed Software development process has dramatically changed over the last decade due to the integration of social collaborative development environment. The pull-based software development methodology made its mark in the open source distributed development as it is a convenient and effective system to organise collaborative contribution. Code reviews for software projects have been a best practice in software engineering. With the emerge of pull-based software development methodology, code reviewers faced difficulty in reviewing the contributions because of the higher number of incoming pull requests. In order to address this problem, reviewer recommendation systems have been implemented. In these systems, textual data mining techniques have been applied. This paper focuses on identifying the different approaches in terms of textual data mining used in the domain of the reviewer recommendations in pull-based software development and identifies their drawbacks and room for improvement. This paper contains the initial part of ongoing research and in the future, we hope to use this knowledge to come up with a solution that addresses the identified drawbacks and the identified improvements.},
author = {Rathnayake, R S and Poravi, G},
booktitle = {2019 IEEE 5th International Conference for Convergence in Technology (I2CT)},
doi = {10.1109/I2CT45611.2019.9033820},
keywords = {data mining;groupware;program testing;recommender systems;software engineering;distributed software development process;social collaborative development environment;pull-based software development methodology;open source distributed development;code reviews;software projects;software engineering;pull requests;reviewer recommendation systems;textual data mining techniques;pull-based distributed software development;Software;Information retrieval;Collaboration;Support vector machines;Text mining;Software engineering;Pull Request;Text Mining;Machine Learning;Reviewer Recommendation;Distributed Software Development},
pages = {1--5},
title = {{Review on Textual Data Mining for Reviewer Recommendation in Pull-Based Distributed Software Development}},
year = {2019}
}
@article{arXiv:2005.10176,
abstract = {Abstract: With tens of millions of projects and developers, the OSS ecosystem is both vibrant and intimidating. On one hand, it hosts the source code for the most critical infrastructures and has the most brilliant developers as contributors, while on the other hand, poor quality or even malicious software, and novice developers abound. External contributions are critical to OSS projects, but the chances their contributions are accepted or even considered depend on the trust between maintainers and contributors. Such trust is built over repeated interactions and coding platforms provide signals of project or developer quality via measures of activity (commits), and social relationships (followers/stars) to facilitate trust. These signals, however, do not represent the specific expertise of a developer. We, therefore, aim to address this gap by defining the skill space for APIs, developers, and projects that reflects what developers know (and projects need) more precisely than could be obtained via aggregate activity counts, and more generally than pointing to individual files developers have changed in the past. Specifically, we use the World of Code infrastructure to extract the complete set of APIs in the files changed by all open source developers. We use that data to represent APIs, developers, and projects in the skill space, and evaluate if the alignment measures in the skill space can predict whether or not the developers use new APIs, join new projects, or get their pull requests accepted. We also check if the developers' representation in the skill space aligns with their self-reported expertise. Our results suggest that the proposed embedding in the skill space achieves our aims and may serve not only as a signal to increase trust (and efficiency) of open source ecosystems, but may also allow more detailed investigations of other phenomena related to developer proficiency and learning. △ Less},
author = {{Authors: Tapajit Dey Andrey Karnauch}, Audris Mockus},
journal = {arXiv preprint arXiv:2005.10176},
title = {{Representation of Developer Expertise in Open Source Software}},
year = {2020}
}
@article{10.1631/FITEE.1700196,
author = {Wang, Cheng YangQiang FanTao WangGang YinXun-hui ZhangYue YuHua-min},
doi = {10.1631/FITEE.1700196},
journal = {Frontiers of Information Technology {\&} Electronic Engineering},
number = {2},
title = {{RepoLike: amulti-feature-based personalized recommendation approach for open-source repositories}},
url = {http://link.springer.com/article/10.1631/FITEE.1700196},
volume = {20},
year = {2019}
}
@inproceedings{Chen2019,
abstract = {Crowdsourcing and data mining can be used to effectively reduce the effort associated with the partial replication and enhancement of qualitative studies. For example, in a primary study, other researchers explored factors influencing the fate of GitHub pull requests using an extensive qualitative analysis of 20 pull requests. Guided by their findings, we mapped some of their qualitative insights onto quantitative questions. To determine how well their findings generalize, we collected much more data (170 additional pull requests from 142 GitHub projects). Using crowdsourcing, that data was augmented with subjective qualitative human opinions about how pull requests extended the original issue. The crowd's answers were then combined with quantitative features and, using data mining, used to build a predictor for whether code would be merged. That predictor was far more accurate than the one built from the primary study's qualitative factors (F1=90 vs 68{\%}), illustrating the value of a mixed-methods approach and replication to improve prior results. To test the generality of this approach, the next step in future work is to conduct other studies that extend qualitative studies with crowdsourcing and data mining.},
author = {Chen, D and Stolee, K T and Menzies, T},
booktitle = {2019 IEEE/ACM 27th International Conference on Program Comprehension (ICPC)},
doi = {10.1109/ICPC.2019.00037},
isbn = {2643-7171 VO -},
keywords = {Crowdsourcing,Data mining,Data models,Feature extraction,GitHub projects,GitHub pull requests,Github,Interviews,Quality control,Replication,Software Engineering,Software engineering,crowdsourcing,data mining,extensive qualitative analysis,mixed-method approach,partial replication,pull request acceptance,qualitative insights,qualitative studies,quantitative questions,regression analysis,social aspects of automation,social networking (online),subjective qualitative human opinions,text analysis},
pages = {179--190},
title = {{Replication Can Improve Prior Results: A GitHub Study of Pull Request Acceptance}},
year = {2019}
}
@article{arXiv:1702.08571,
abstract = {Abstract: Due to the difficulties in replicating and scaling up qualitative studies, such studies are rarely verified. Accordingly, in this paper, we leverage the advantages of crowdsourcing (low costs, fast speed, scalable workforce) to replicate and scale-up one state-of-the-art qualitative study. That qualitative study explored 20 GitHub pull requests to learn factors that influence the fate of pull requests with respect to approval and merging. As a secondary study, using crowdsourcing at a cost of {\$}200, we studied 250 pull requests from 142 GitHub projects. The prior qualitative findings are mapped into questions for crowds workers. Their answers were converted into binary features to build a predictor which predicts whether code would be merged with median F1 scores of 68{\%}. For the same large group of pull requests, the median F1 scores could achieve 90{\%} by a predictor built with additional features defined by prior quantitative results. Based on this case study, we conclude that there is much benefit in combining different kinds of research methods. While qualitative insights are very useful for finding novel insights, they can be hard to scale or replicate. That said, they can guide and define the goals of scalable secondary studies that use (e.g.) crowdsourcing+data mining. On the other hand, while data mining methods are reproducible and scalable to large data sets, their results may be spectacularly wrong since they lack contextual information. That said, they can be used to test the stability and external validity, of the insights gained from a qualitative analysis. △ Less},
author = {{Authors: Di Chen Kathryn T. Stolee}, Tim Menzies},
journal = {arXiv preprint arXiv:1702.08571},
title = {{Replicating and Scaling up Qualitative Analysis using Crowdsourcing: A Github-based Case Study}},
year = {2017}
}
@inproceedings{10.1145/3239235.3240504,
abstract = {Background Open source software projects show gender bias suggesting that other demographic characteristics of developers, like geographical location, can negatively influence evaluation of contributions too. Aim This study contributes to this emerging body of knowledge in software development by presenting a quantitative analysis of the relationship between the geographical location of developers and evaluation of their contributions on GitHub. Method We present an analysis of 70,000+ pull requests selected from 17 most actively participating countries to model the relationship between the geographical location of developers and pull request acceptance decision. Results and Conclusion We observed structural differences in pull request acceptance rates across 17 countries. Countries with no apparent similarities such as Switzerland and Japan had one of the highest pull request acceptance rates while countries like China and Germany had one of the lowest pull request acceptance rates. Notably, higher acceptance rates were observed for all but one country when pull requests were evaluated by developers from the same country.},
address = {New York, NY, USA},
author = {Rastogi, Ayushi and Nagappan, Nachiappan and Gousios, Georgios and van der Hoek, Andr{\'{e}}},
booktitle = {Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement},
doi = {10.1145/3239235.3240504},
isbn = {9781450358231},
keywords = { geographical location, github, open source,pull requests},
publisher = {Association for Computing Machinery},
series = {ESEM '18},
title = {{Relationship between Geographical Location and Evaluation of Developer Contributions in Github}},
url = {https://doi.org/10.1145/3239235.3240504},
year = {2018}
}
@inproceedings{Soares2015,
abstract = {When developers want to contribute to an opensource project, they fork the repository, make changes, and send a pull request to the core team to incorporate these changes back into the repository. However, some projects enforce this collaboration model even for changes made by core team developers. This potentially enhances the quality of the repository by adding an inspection step before accepting a contribution into the repository. In this context, though less frequently, the contributions may be rejected. The understanding of the factors that lead to the rejection of these internal contributions is crucial for the improvement of the ways core developers collaborate, having a direct impact on the team productivity. In this work we extract association rules from pull request data stored in software repositories in order to find factors that have influence over the decision of rejecting contributions made by core developers. In addition, we present a qualitative analysis of some cases, helping to understand the patterns that arose from the association rules. The results indicate that some key factors increase the changes of having internal contributions rejected: (i) the inexperience with pull requests, (ii) the complexity of contributions, as well as the locality of the artifacts that have been modified, and (iii) the contribution policy of the projects.},
author = {Soares, D M and Junior, M L De Lima and Murta, L and Plastino, A},
booktitle = {2015 IEEE 14th International Conference on Machine Learning and Applications (ICMLA)},
doi = {10.1109/ICMLA.2015.41},
isbn = { VO -},
keywords = {Collaboration,Computational modeling,Context,Data mining,Databases,Measurement,Software,association rules,collaboration model,data mining,groupware,high acceptance rates,inspection step,opensource project,public domain software,pull request,pull request data,rejection factors,software engineering,software management,software projects,software repositories},
pages = {960--965},
title = {{Rejection Factors of Pull Requests Filed by Core Team Developers in Software Projects with High Acceptance Rates}},
year = {2015}
}
@inproceedings{10.1109/ASE.2019.00081,
abstract = {The adoption of refactoring techniques for continuous integration received much less attention from the research community comparing to root-canal refactoring to fix the quality issues in the whole system. Several recent empirical studies show that developers, in practice, are applying refactoring incrementally when they are fixing bugs or adding new features. There is an urgent need for refactoring tools that can support continuous integration and some recent development processes such as DevOps that are based on rapid releases. Furthermore, several studies show that manual refactoring is expensive and existing automated refactoring tools are challenging to configure and integrate into the development pipelines with significant disruption cost.In this paper, we propose, for the first time, an intelligent software refactoring bot, called RefBot. Integrated into the version control system (e.g. GitHub), our bot continuously monitors the software repository, and it is triggered by any "open" or "merge" action on pull requests. The bot analyzes the files changed during that pull request to identify refactoring opportunities using a set of quality attributes then it will find the best sequence of refactorings to fix the quality issues if any. The bot recommends all these refactorings through an automatically generated pull-request. The developer can review the recommendations and their impacts in a detailed report and select the code changes that he wants to keep or ignore. After this review, the developer can close and approve the merge of the bot's pull request. We quantitatively and qualitatively evaluated the performance and effectiveness of RefBot by a survey conducted with experienced developers who used the bot on both open source and industry projects.},
author = {Alizadeh, Vahid and Ouali, Mohamed Amine and Kessentini, Marouane and Chater, Meriem},
booktitle = {Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering},
doi = {10.1109/ASE.2019.00081},
isbn = {9781728125084},
keywords = { quality, refactoring,Software bot},
pages = {823--834},
publisher = {IEEE Press},
series = {ASE '19},
title = {{RefBot: Intelligent Software Refactoring Bot}},
url = {https://doi.org/10.1109/ASE.2019.00081},
year = {2019}
}
@article{9174755,
abstract = {OSS projects are being developed by globally distributed contributors, who often collaborate through the pull-based model today. While this model lowers the barrier to entry for OSS developers by synthesizing, automating and optimizing the contribution process, coordination among an increasing number of contributors remains as a challenge due to the asynchronous and self-organized nature of distributed development. In particular, duplicate contributions, where multiple different contributors unintentionally submit duplicate pull requests to achieve the same goal, are an elusive problem that may waste effort in automated testing, code review and software maintenance. While the issue of duplicate pull requests has been highlighted, to what extent duplicate pull requests affect the development in OSS communities has not been well investigated. In this paper, we conduct a mixed-approach study to bridge this gap. Based on a comprehensive dataset constructed from 26 popular GitHub projects, we obtain the following findings: (a) Duplicate pull requests result in redundant human and computing resources, exerting a significant impact on the contribution and evaluation process. (b) Contributors' inappropriate working patterns and the drawbacks of their collaborating environment might result in duplicate pull requests. (c) Compared to non-duplicate pull requests, duplicate pull requests have significantly different features, e.g., being submitted by inexperienced contributors, being fixing bugs, touching cold files, and solving tracked issues. (d) Integrators choosing between duplicate pull requests prefer to accept those with early submission time, accurate and high-quality implementation, broad coverage, test code, high maturity, deep discussion, and active response. Finally, actionable suggestions and implications are proposed for OSS practitioners.},
author = {Li, Z and Yu, Y and Zhou, M and Wang, T and Yin, G and Lan, L and Wang, H},
doi = {10.1109/TSE.2020.3018726},
issn = {1939-3520},
journal = {IEEE Transactions on Software Engineering},
keywords = {Duplicate pull requests;pull-based development model;distributed collaboration;social coding},
pages = {1},
title = {{Redundancy, Context, and Preference: An Empirical Study of Duplicate Pull Requests in OSS Projects}},
year = {2020}
}
@inproceedings{8330247,
abstract = {Software systems change frequently over time, either due to new business requirements or technology pressures. Programming languages evolve in a similar constant fashion, though when a language release introduces new programming constructs, older constructs and idioms might become obsolete. The coexistence between newer and older constructs leads to several problems, such as increased maintenance efforts and steeper learning curve for developers. In this paper we present a RASCAL Java transformation library that evolves legacy systems to use more recent programming language constructs (such as multi-catch and lambda expressions). In order to understand how relevant automatic software rejuvenation is, we submitted 2462 transformations to 40 open source projects via the GitHub pull request mechanism. Initial results show that simple transformations, for instance the introduction of the diamond operator, are more likely to be accepted than transformations that change the code substantially, such as refactoring enhanced for loops to the newer functional style.},
author = {Dantas, R and Carvalho, A and Marc{\'{i}}lio, D and Fantin, L and Silva, U and Lucas, W and Bonif{\'{a}}cio, R},
booktitle = {2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER.2018.8330247},
keywords = {Java;learning (artificial intelligence);object-oriented programming;public domain software;software maintenance;software metrics;software quality;source code transformations;Java programs;business requirements;programming languages;idioms;steeper learning curve;RASCAL Java transformation library;legacy systems;lambda expressions;GitHub pull request mechanism;software systems;maintenance efforts;open source projects;programming language constructs;automatic software rejuvenation;Java;Aging;Tools;Libraries;Diamond;Syntactics},
pages = {497--501},
title = {{Reconciling the past and the present: An empirical study on the application of source code transformations to automatically rejuvenate Java programs}},
year = {2018}
}
@inproceedings{10.1145/2666539.2666570,
abstract = { Social coding sites (e.g., Github) provide various features like Forking and Sending Pull-requests to support crowd-based software engineering. When using these features, a large amount of user behavior data is recorded. User behavior data can reflect developers preferences and interests in software development activities. Online service providers in many fields have been using user behavior data to discover user preferences and interests to achieve various purposes. In the field of software engineering however, there has been few studies in mining large amount of user behavior data. Our goal is to design an approach based on user behavior data, to recommend relevant open source projects to developers, which can be helpful in activities like searching for the right open source solutions to quickly build prototypes. In this paper, we explore the possibilities of such a method by conducting a set of experiments on selected data sets from Github. We find it a promising direction in mining projects' relevance from user behavior data. Our study also obtain some important issues that is worth considering in this method. },
address = {New York, NY, USA},
author = {Zhang, Lingxiao and Zou, Yanzhen and Xie, Bing and Zhu, Zixiao},
booktitle = {Proceedings of the 1st International Workshop on Crowd-Based Software Development Methods and Technologies},
doi = {10.1145/2666539.2666570},
isbn = {9781450332248},
keywords = { Crowd-base software engineering, Github, Social coding,Recommendation system},
pages = {25--30},
publisher = {Association for Computing Machinery},
series = {CrowdSoft 2014},
title = {{Recommending Relevant Projects via User Behaviour: An Exploratory Study on Github}},
url = {https://doi.org/10.1145/2666539.2666570},
year = {2014}
}
@article{10.1007/s11432-017-9465-9,
abstract = {The latest query expansion (QE) methods use the software development features for expanding queries. However, these methods allow only one feature to be considered at a time. To consider additional features simultaneously, we propose a QE method based on Github knowledge; this is a new comprehensive feature that covers both the existing features (i.e., the application program interface (API) information and crowd knowledge). It is extracted from the “pull requests” of code repositories on Github, which contain descriptions of a request and its commits, the participants' comments and the API information of the changed files. In addition, we implement a black-box framework that integrates multiple QE methods based on the support vector machine ranking called Github knowledge search repository (GKSR). Our empirical evaluation shows that the GKSR outperforms the state-of-the-art QE methods CodeHow and QECK by 25{\%}–32{\%} in terms of precision.},
author = {Wu, Qing HuangHuaiguang},
doi = {10.1007/s11432-017-9465-9},
journal = {Science China Information Sciences},
number = {5},
title = {{QE-integrating framework based on Github knowledge and SVM ranking}},
url = {http://link.springer.com/article/10.1007/s11432-017-9465-9},
volume = {62},
year = {2019}
}
@article{arXiv:1809.10948,
abstract = {Abstract: In Named Data Networking (NDN), there is a need for routing protocols to populate Forwarding Information Base (FIB) tables so that the Interest messages can be forwarded. To populate FIBs, clients and routers require some routing information. One method to obtain this information is that network nodes exchange routing information by each node advertising the available content objects. Bloom Filter-based Routing approaches like BFR [1], use Bloom Filters (BFs) to advertise all provided content objects, which consumes valuable bandwidth and storage resources. This strategy is inefficient as clients request only a small number of the provided content objects and they do not need the content advertisement information for all provided content objects. In this paper, we propose a novel routing algorithm for NDN called pull-based BFR in which servers only advertise the demanded file names. We compare the performance of pull-based BFR with original BFR and with a flooding-assisted routing protocol. Our experimental evaluations show that pull-based BFR outperforms original BFR in terms of communication overhead needed for content advertisements, average roundtrip delay, memory resources needed for storing content advertisements at clients and routers, and the impact of false positive reports on routing. The comparisons also show that pull-based BFR outperforms flooding-assisted routing in terms of average round-trip delay. △ Less},
author = {{Authors: Ali Marandi Torsten Braun}, Kave Salamatian Nikolaos Thomos},
journal = {arXiv preprint arXiv:1809.10948},
title = {{Pull-based Bloom Filter-based Routing for Information-Centric Networks}},
year = {2018}
}
@inproceedings{Bertoncello2020,
abstract = {Social coding environments have been consistently growing since the popularization of the contribution model known as pull-based. This model has facilitated how developers make their contributions; developers can easily place a few pull requests without further commitment. Developers without strong ties to a project, the so-called casual contributors, often make a single contribution before disappearing. Interestingly, some studies about the topic use the number of commits made to identify the casual contributors, while others use the number of merged pull requests. Does the method used influence the results? In this paper, we replicate a study about casual contributors that relied on commits to identify and analyze these contributors. To achieve this goal, we analyzed the same set of GitHub-hosted software repositories used in the original paper. By using pull requests, we found an average of 66{\%} casual contributors (in comparison to 48.98{\%} when using commits), who were responsible for 12.5{\%} of the contributions accepted (1.73{\%} when using commits). We used a sample of 442 developers to investigate the accuracy of the method. We found that 11.3{\%} of the contributors identified using the pull requests were misclassified (26.2{\%} using commits). We also evidenced that using pull requests is more precise for determining the number of contributions, given that GitHub projects mostly follow the pull-based process. Our results indicate that the method used for mining contributors' data has the potential to influence the results. With this replication, it may be possible to improve previous results and reduce future efforts for new researchers when conducting studies that rely on the number of contributions.},
author = {Bertoncello, M V and Pinto, G and Wiese, I S and Steinmacher, I},
booktitle = {2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER48275.2020.9054855},
isbn = {1534-5351 VO -},
keywords = {Casual contributors,Open source,Replication,commits,contribution model,contributors behavior,contributors data mining,data mining,open source software,project management,public domain software,pull requests,pull-based process,social coding environments,software engineering,software management},
pages = {592--601},
title = {{Pull Requests or Commits? Which Method Should We Use to Study Contributors' Behavior?}},
year = {2020}
}
@article{rostami2016pull,
author = {Rostami, Vahid},
journal = {Elephant Github},
title = {{Pull Request of the Unitary Events method in Elephant}},
year = {2016}
}
@article{gousios2016pull,
abstract = {Some features of this site may not work without it. Title: Pull request contributors analysis dataset. Creators: Gousios, G.; Storey, M.-A.; Bacchelli, A. Date of Archiving: 2016. Archive: Zenodo. DOI: https://doi.org/10.5281/zenodo.46063. Publication type: Dataset. Access level : open access},
author = {Gousios, G and Storey, M-A and Bacchelli, A},
publisher = {Zenodo},
title = {{Pull request contributors analysis dataset}},
url = {https://repository.ubn.ru.nl/handle/2066/167422},
year = {2016}
}
@inproceedings{Roque2019,
abstract = {Although recognized as important, programming style is one aspect commonly neglected by developers. However, follow the pattern of programming presents in a project may be useful to understand and maintain the system. Usually, the companies build their own guidelines for coding bug fixes or new features. Nonetheless, developing this set of rules is not a simple task, and there are even inconsistencies in the specialized literature. Therefore, this paper proposes a new approach to programming style analysis, using a recurrent neural network (RNN) that learns the programming style presents in a project and determines whether a piece of code submitted to it, follows the project's pattern. A study on three real projects was conducted and demonstrated the promising of the approach, by revealing the RNN capability to recognize the programming style pattern of each project.},
author = {Roque, L and Dantas, A and Camilo-Junior, C G},
booktitle = {2019 International Joint Conference on Neural Networks (IJCNN)},
doi = {10.1109/IJCNN.2019.8852255},
isbn = {2161-4407 VO -},
keywords = {Biological neural networks,LSTM.,Neurons,Programming,Programming Style,RNN,Recurrent Neural Networks,Recurrent neural networks,Software,Training,bug coding,learning (artificial intelligence),program debugging,programming,programming style analysis,programming style pattern,pull request Paradigm,pull request approval,recurrent neural nets,recurrent neural network},
pages = {1--7},
title = {{Programming Style Analysis with Recurrent Neural Network to Automatic Pull Request Approval}},
year = {2019}
}
@article{10.1007/s10844-017-0484-1,
author = {Stencel, Miko{\l}aj FejzerPiotr PrzymusKrzysztof},
doi = {10.1007/s10844-017-0484-1},
journal = {Journal of Intelligent Information Systems},
number = {3},
title = {{Profile based recommendation of code reviewers}},
url = {http://link.springer.com/article/10.1007/s10844-017-0484-1},
volume = {50},
year = {2018}
}
@article{arXiv:1803.10198,
abstract = {Abstract: Programming languages and platforms improve over time, sometimes resulting in new language features that offer many benefits. However, despite these benefits, developers may not always be willing to adopt them in their projects for various reasons. In this paper, we describe an empirical study where we assess the adoption of a particular new language feature. Studying how developers use (or do not use) new language features is important in programming language research and engineering because it gives designers insight into the usability of the language to create meaning programs in that language. This knowledge, in turn, can drive future innovations in the area. Here, we explore Java 8 default methods, which allow interfaces to contain (instance) method implementations. Default methods can ease interface evolution, make certain ubiquitous design patterns redundant, and improve both modularity and maintainability. A focus of this work is to discover, through a scientific approach and a novel technique, situations where developers found these constructs useful and where they did not, and the reasons for each. Although several studies center around assessing new language features, to the best of our knowledge, this kind of construct has not been previously considered. Despite their benefits, we found that developers did not adopt default methods in all situations. Our study consisted of submitting pull requests introducing the language feature to 19 real-world, open source Java projects without altering original program semantics. This novel assessment technique is proactive in that the adoption was driven by an automatic refactoring approach rather than waiting for developers to discover and integrate the feature themselves. In this way, we set forth best practices and patterns of using the language feature effectively earlier rather than later and are able to possibly guide (near) future language evolution. We foresee this technique to be useful in assessing other new language features, design patterns, and other programming idioms. △ Less},
author = {{Authors: Raffi Khatchadourian}, Hidehiko Masuhara},
doi = {10.22152/programming-journal.org/2018/2/6},
journal = {arXiv preprint arXiv:1803.10198},
title = {{Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods}},
year = {2018}
}
@inproceedings{10.1145/2814189.2814197,
abstract = { In collaborative software development, developers submit their contributions, such as code commits or pull requests, to a repository. Often, this code contribution is reviewed in order to avoid privacy and security problems. Manual code review is a common way to detect such problems, but it is expensive, error-prone, and time consuming. Other automatic approaches are either designed for specific domains, such as Android platform, or demand significant effort from developers. To minimize these problems, we propose a new policy language to allow developers to specify constraints for code contributions and to enforce them between existing code and new code contributions. Our language implementation automatically checks adherence of new code contributions to these constraints for systems of different domains without demanding further effort from developers. Moreover, we plan to evaluate it regarding effectiveness and reduction of effort in finding privacy and security violations. },
address = {New York, NY, USA},
author = {Andrade, Rodrigo},
booktitle = {Companion Proceedings of the 2015 ACM SIGPLAN International Conference on Systems, Programming, Languages and Applications: Software for Humanity},
doi = {10.1145/2814189.2814197},
isbn = {9781450337229},
keywords = { Constraint, Information Flow Control, Policy language,Code Contribution},
pages = {27--29},
publisher = {Association for Computing Machinery},
series = {SPLASH Companion 2015},
title = {{Privacy and Security Constraints for Code Contributions}},
url = {https://doi.org/10.1145/2814189.2814197},
year = {2015}
}
@inproceedings{Mohamed2018,
abstract = {In GitHub, integrators inspect submitted code changes, make evaluation decision, and close pull requests. However, some pull requests may get reopened for further modification and code review. It is important to predict reopened pull requests immediately after pull requests' first close, and help integrators reopen pull requests in time. If pull requests are reopened a long time after their close, they may cause conflicts with newly submitted pull requests, add software maintenance cost, and increase burden for already busy developers. To the best of our knowledge, we present the first look at predicting reopened pull requests in GitHub. We propose an approach DTPre which is an automatic predictor of reopened pull requests based on Decision Tree classifier. DTPre mainly analyzes code features of modified changes, review features during evaluation, and developer feature of contributors. We evaluate the effectiveness of DTPre on 7 Open Source projects containing 100,622 pull requests. Experimental results show that DTPre has high performances by achieving a precision of 95.53{\%}, recall of 99.01{\%} and F1-measure of 97.23{\%} on average. In comparison with predictors based on neural network, na{\"{i}}ve Bayes, logistic regression and SVM, DTPre based on decision tree improves F-1 measures by 41.76{\%}, 59.45{\%}, 42.25{\%} and 9.98{\%} on average across 7 projects.},
author = {Mohamed, A and Zhang, L and Jiang, J and Ktob, A},
booktitle = {2018 25th Asia-Pacific Software Engineering Conference (APSEC)},
doi = {10.1109/APSEC.2018.00052},
isbn = {2640-0715 VO -},
keywords = {Bayes methods,Buildings,Computer bugs,Computer science,DTPre,Decision trees,Feature extraction,GitHub,Neural networks,Predictive models,Reopened pull requests, Prediction, Code review, G,SVM,code review,decision tree classifier,decision trees,logistic regression,naive bayes,neural nets,neural network,open source projects,pattern classification,public domain software,regression analysis,reopened pull requests,software maintenance,software maintenance cost,support vector machines},
pages = {375--385},
title = {{Predicting Which Pull Requests Will Get Reopened in GitHub}},
year = {2018}
}
@inproceedings{8870173,
abstract = {Background. During collaborative software development, developers often use branches to add features or fix bugs. When merging changes from two branches, conflicts may occur if the changes are inconsistent. Developers need to resolve these conflicts before completing the merge, which is an error-prone and time-consuming process. Early detection of merge conflicts, which warns developers about resolving conflicts before they become large and complicated, is among the ways of dealing with this problem. Existing techniques do this by continuously pulling and merging all combinations of branches in the background to notify developers as soon as a conflict occurs, which is a computationally expensive process. One potential way for reducing this cost is to use a machine-learning based conflict predictor that filters out the merge scenarios that are not likely to have conflicts, i.e.safe merge scenarios.Aims. In this paper, we assess if conflict prediction is feasible.Method. We design a classifier for predicting merge conflicts, based on 9 light-weight Git feature sets. To evaluate our predictor, we perform a large-scale study on 267,657 merge scenarios from 744 GitHub repositories in seven programming languages.Results. Our results show that we achieve high f1-scores, varying from 0.95 to 0.97 for different programming languages, when predicting safe merge scenarios. The f1-score is between 0.57 and 0.68 for the conflicting merge scenarios.Conclusions. Predicting merge conflicts is feasible in practice, especially in the context of predicting safe merge scenarios as a pre-filtering step for speculative merging.},
author = {Owhadi-Kareshk, M and Nadi, S and Rubin, J},
booktitle = {2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)},
doi = {10.1109/ESEM.2019.8870173},
issn = {1949-3789},
keywords = {learning (artificial intelligence);merging;program debugging;software engineering;merging changes;machine-learning based conflict predictor;conflict prediction;speculative merging;collaborative software development;merge conflicts;programming languages;light-weight Git feature sets;Merging;Computer languages;Feature extraction;Software;Tools;Machine learning;Correlation;Conflict Prediction;Git;Software Merging},
pages = {1--11},
title = {{Predicting Merge Conflicts in Collaborative Software Development}},
year = {2019}
}
@inproceedings{10.1145/3139903.3139916,
abstract = {Collaborative software development platforms such as GitHub simplify the process of contributing into open source projects by the use of a pull request. The decision of accepting or rejecting a pull request has to be made by an integrator. Because reviewing a pull request can be time consuming, social factors are known to have an important effect on the acceptation of a pull request. This effect can be especially important for large and complicated pull request.In this paper we present Git Thermite, a tool to assess the internal structure of a pull request and simplifying the job of the integrator. Git Thermite details the structural changes made on the source code. In Git Thermite we use a pull request business card visual metaphor for describing a pull request. In this business card, we present the pull request metadata and describe the modified files, and the structural changes in the modified source code.},
address = {New York, NY, USA},
author = {Salgado, Ronie and Bergel, Alexandre},
booktitle = {Proceedings of the 12th Edition of the International Workshop on Smalltalk Technologies},
doi = {10.1145/3139903.3139916},
isbn = {9781450355544},
publisher = {Association for Computing Machinery},
series = {IWST '17},
title = {{Pharo Git Thermite: A Visual Tool for Deciding to Weld a Pull Request}},
url = {https://doi.org/10.1145/3139903.3139916},
year = {2017}
}
@inproceedings{8479462,
abstract = {The phenomenon of open-source software (OSS) has gained importance among the information technology (IT) firms and software entrepreneurial ventures in the recent years due to its advantages over proprietary closed software including high level of innovation, low cost of development, availability of reusable architectural and functional component, free and unrestrictive access to the source codes. The firms have started recognizing the importance and value of the open source software over the proprietary closed software. It is important to understand and analyze various characteristics of the OSS projects which influence their performance. In this research, we examine OSS project characteristics forks count, number of contributors, project age, project size, project owner, number of programming languages used, primary language intensity, and watchers using 130 project repositories which are started in 2017 from GitHub one of the leading web-based Git version control repository hosting services. A conceptual model of OSS Project performance and hypotheses are developed. The results conclude that the number of programming languages, the project size, the number of contributors, and the project age are showing significant positive influence on the OSS project performance. The project ownership and the primary language are not showing any significant influence on the OSS project performance.},
author = {Joy, A and Thangavelu, S and Jyotishi, A},
booktitle = {2018 Second International Conference on Advances in Electronics, Computers and Communications (ICAECC)},
doi = {10.1109/ICAECC.2018.8479462},
keywords = {Internet;public domain software;source code (software);GitHub open-source software project;software entrepreneurial ventures;reusable architectural component;functional component;source codes;OSS projects;programming languages;information technology;proprietary closed software;web-based Git version control repository hosting services;Technological innovation;Computer languages;Open source software;Social network services;Organizations;Mathematical model;Open source software;GitHub;forks count;primary language intensity;watchers;econometric analysis},
pages = {1--6},
title = {{Performance of GitHub Open-Source Software Project: An Empirical Analysis}},
year = {2018}
}
@article{arXiv:1907.06538,
abstract = {Background: Open source requires participation of volunteer and commercial developers (users) in order to deliver functional high-quality components. Developers both contribute effort in the form of patches and demand effort from the component maintainers to resolve issues reported against it. Open source components depend on each other directly and transitively, and evidence suggests that more effort is required for reporting and resolving the issues reported further upstream in this supply chain. Aim: Identify and characterize patterns of effort contribution and demand throughout the open source supply chain and investigate if and how these patterns vary with developer activity; identify different groups of developers; and predict developers' company affiliation based on their participation patterns. Method: 1,376,946 issues and pull-requests created for 4433 NPM packages with over 10,000 monthly downloads and full (public) commit activity data of the 272,142 issue creators is obtained and analyzed and dependencies on NPM packages are identified. Fuzzy c-means clustering algorithm is used to find the groups among the users based on their effort contribution and demand patterns, and Random Forest is used as the predictive modeling technique to identify their company affiliations. Result: Users contribute and demand effort primarily from packages that they depend on directly with only a tiny fraction of contributions and demand going to transitive dependencies. A significant portion of demand goes into packages outside the users' respective supply chains (constructed based on publicly visible version control data). Three and two different groups of users are observed based on the effort demand and effort contribution patterns respectively. The Random Forest model used for identifying the company affiliation of the users gives a AUC-ROC value of 0.68, and variables representing aggregate participation patterns proved to be the important predictors. Conclusion: Our results give new insights into effort demand and supply at different parts of the supply chain of the NPM ecosystem and its users and suggests the need to increase visibility further upstream.},
address = {New York, NY, USA},
author = {{Authors: Tapajit Dey Yuxing Ma}, Audris Mockus and Dey, Tapajit and Ma, Yuxing and Mockus, Audris},
doi = {10.1145/3345629.3345634},
isbn = {9781450372336},
journal = {Proceedings of the Fifteenth International Conference on Predictive Models and Data Analytics in Software Engineering},
keywords = {,Clustering,NPM Packages,Random Forest model,Software Dependencies,Software Issue Reporting,User Contribution},
pages = {36--45},
publisher = {Association for Computing Machinery},
series = {PROMISE'19},
title = {{Patterns of Effort Contribution and Demand and User Classification Based on Participation Patterns in NPM Ecosystem}},
url = {https://doi.org/10.1145/3345629.3345634},
year = {2019}
}
@inproceedings{10.1145/3183377.3183394,
abstract = {Introducing Open Source Software (OSS) projects into a software-engineering course has many advantages, for instance, allowing students to learn good coding practices from real-world projects, and giving students a glimpse of a real project. However, it is not easy for instructors to induce one or more OSS core teams to lend support for course projects. The alternative is to have students work on "toy features"---features for these projects not specified by OSS core teams, but by teaching staff. However, the project may be unimportant to the OSS project or may disrupt its design, making those code contributions unlikely to be integrated into the OSS code repository. In this paper, we, as both teaching staff and the core team for one OSS project called Expertiza, discuss our experience in supporting 700 students on 313 OSS-based course projects in the past five years. We manually checked these course projects, and summarize 13 common mistakes that frequently occur in students' contributions, such as not following the existing design or messy pull requests. We propose five suggestions to help students reduce the frequency of common mistakes and improve the quality of their OSS pull requests.},
address = {New York, NY, USA},
author = {Hu, Zhewei and Song, Yang and Gehringer, Edward F},
booktitle = {Proceedings of the 40th International Conference on Software Engineering: Software Engineering Education and Training},
doi = {10.1145/3183377.3183394},
isbn = {9781450356602},
keywords = { expertiza, open-source curriculum, software engineering,open-source software},
pages = {40--48},
publisher = {Association for Computing Machinery},
series = {ICSE-SEET '18},
title = {{Open-Source Software in Class: Students' Common Mistakes}},
url = {https://doi.org/10.1145/3183377.3183394},
year = {2018}
}
@inproceedings{zhang2020shoulders,
abstract = {Pull-based development is a widely adopted paradigm for collaboration in distributed software development, attracting eyeballs from both academic and industry. To better study pull-based development model, this paper presents a new dataset containing 96 features},
author = {Zhang, Xunhui and Rastogi, Ayushi and Yu, Yue},
booktitle = {Conference on Mining Software Repositories (MSR'20)},
title = {{On the Shoulders of Giants: A New Dataset for Pull-based Development Research}},
url = {https://www.researchgate.net/profile/Xunhui{\_}Zhang/publication/342529857{\_}On{\_}the{\_}Shoulders{\_}of{\_}Giants{\_}A{\_}New{\_}Dataset{\_}for{\_}Pull-based{\_}Development{\_}Research/links/5ef9f1b7a6fdcc4ca43a419e/On-the-Shoulders-of-Giants-A-New-Dataset-for-Pull-based-Development-Research.pdf},
year = {2020}
}
@article{10.1007/s10664-019-09774-x,
author = {{de AlmeidaSven Apel}, Gustavo ValeAngelika SchmidAlcemir Rodrigues SantosEduardo Santana},
doi = {10.1007/s10664-019-09774-x},
journal = {Empirical Software Engineering},
number = {1},
title = {{On the relation between Github communication activity and merge conflicts}},
url = {http://link.springer.com/article/10.1007/s10664-019-09774-x},
volume = {25},
year = {2020}
}
@article{10.1007/s10664-019-09792-9,
author = {Shihab, Rabe AbdalkareemVinicius OdaSuhaib MujahidEmad},
doi = {10.1007/s10664-019-09792-9},
journal = {Empirical Software Engineering},
number = {2},
title = {{On the impact of using trivial packages: an empirical case study on npm and PyPI}},
url = {http://link.springer.com/article/10.1007/s10664-019-09792-9},
volume = {25},
year = {2020}
}
@article{DBLP:conf/benevol/LegayDM18,
abstract = {Abstract: The pull-based development process has become prevalent on platforms such as GitHub as a form of distributed software development. Potential contributors can create and submit a set of changes to a software project through pull requests. These changes can be accepted, discussed or rejected by the maintainers of the software project, and can influence further contribution proposals. As such, it is important to examine the practices that encourage contributors to a project to submit pull requests. Specifically, we consider the impact of prior pull requests on the acceptance or rejection of subsequent pull requests. We also consider the potential effect of rejecting or ignoring pull requests on further contributions. In this preliminary research, we study three large projects on $\backslash$textsf{\{}GitHub{\}}, using pull request data obtained through the $\backslash$textsf{\{}GitHub{\}} API, and we perform empirical analyses to investigate the above questions. Our results show that continued contribution to a project is correlated with higher pull request acceptance rates and that pull request rejections lead to fewer future contributions. △ Less},
archivePrefix = {arXiv},
arxivId = {1812.06269},
author = {Legay, Damien and Decan, Alexandre and Mens, Tom and {Authors: Damien Legay Alexandre Decan}, Tom Mens and Legay, Damien and Decan, Alexandre and Mens, Tom},
editor = {Gousios, Georgios and Hejderup, Joseph},
eprint = {1812.06269},
journal = {Proceedings of the 17th Belgium-Netherlands Software Evolution Workshop, Delft, the Netherlands, December 10th - to - 11th, 2018},
pages = {46--50},
publisher = {CEUR-WS.org},
series = {{\{}CEUR{\}} Workshop Proceedings},
title = {{On the impact of pull request decisions on future contributions}},
url = {http://ceur-ws.org/Vol-2361/short12.pdf http://arxiv.org/abs/1812.06269},
volume = {abs/1812.06269},
year = {2018}
}
@inproceedings{DBLP:conf/benevol/GolzadehDM19,
author = {Golzadeh, Mehdi and Decan, Alexandre and Mens, Tom},
booktitle = {Proceedings of the 18th Belgium-Netherlands Software Evolution Workshop, Brussels, Belgium, November 28th to 29th, 2019},
editor = {Nucci, Dario Di and Roover, Coen De},
publisher = {CEUR-WS.org},
series = {{\{}CEUR{\}} Workshop Proceedings},
title = {{On the Effect of Discussions on Pull Request Decisions}},
url = {http://ceur-ws.org/Vol-2605/16.pdf},
volume = {2605},
year = {2019}
}
@article{10.1007/s10664-018-9609-6,
author = {Gerosa, Gustavo PintoIgor SteinmacherLuiz Felipe DiasMarco},
doi = {10.1007/s10664-018-9609-6},
journal = {Empirical Software Engineering},
number = {6},
title = {{On the challenges of open-sourcing proprietary software projects}},
url = {http://link.springer.com/article/10.1007/s10664-018-9609-6},
volume = {23},
year = {2018}
}
@article{10.1007/s10664-016-9493-x,
abstract = {Recent years have seen an increasing attention to social aspects of software engineering, including studies of emotions and sentiments experienced and expressed by the software developers. Most of these studies reuse existing sentiment analysis tools such as SENTISTRENGTH and NLTK. However, these tools have been trained on product reviews and movie reviews and, therefore, their results might not be applicable in the software engineering domain. In this paper we study whether the sentiment analysis tools agree with the sentiment recognized by human evaluators (as reported in an earlier study) as well as with each other. Furthermore, we evaluate the impact of the choice of a sentiment analysis tool on software engineering studies by conducting a simple study of differences in issue resolution times for positive, negative and neutral texts. We repeat the study for seven datasets (issue trackers and STACK OVERFLOW questions) and different sentiment analysis tools and observe that the disagreement between the tools can lead to diverging conclusions. Finally, we perform two replications of previously published studies and observe that the results of those studies cannot be confirmed when a different sentiment analysis tool is used.},
author = {Serebrenik, Robbert JongelingProshanta SarkarSubhajit DattaAlexander},
doi = {10.1007/s10664-016-9493-x},
journal = {Empirical Software Engineering},
number = {5},
title = {{On negative results when using sentiment analysis tools for software engineering research}},
url = {http://link.springer.com/article/10.1007/s10664-016-9493-x},
volume = {22},
year = {2017}
}
@article{arXiv:1901.09102,
abstract = {Abstract: Recent years have seen the rise of Deep Learning (DL) techniques applied to source code. Researchers have exploited DL to automate several development and maintenance tasks, such as writing commit messages, generating comments and detecting vulnerabilities among others. One of the long lasting dreams of applying DL to source code is the possibility to automate non-trivial coding activities. While some steps in this direction have been taken (e.g., learning how to fix bugs), there is still a glaring lack of empirical evidence on the types of code changes that can be learned and automatically applied by DL. Our goal is to make this first important step by quantitatively and qualitatively investigating the ability of a Neural Machine Translation (NMT) model to learn how to automatically apply code changes implemented by developers during pull requests. We train and experiment with the NMT model on a set of 236k pairs of code components before and after the implementation of the changes provided in the pull requests. We show that, when applied in a narrow enough context (i.e., small/medium-sized pairs of methods before/after the pull request changes), NMT can automatically replicate the changes implemented by developers during pull requests in up to 36{\%} of the cases. Moreover, our qualitative analysis shows that the model is capable of learning and replicating a wide variety of meaningful code changes, especially refactorings and bug-fixing activities. Our results pave the way for novel research in the area of DL on code, such as the automatic learning and applications of refactoring. △ Less},
author = {Tufano, Michele and Pantiuchina, Jevgenija and Watson, Cody and Bavota, Gabriele and Poshyvanyk, Denys and {Authors: Michele Tufano Jevgenija Pantiuchina}, Cody Watson Gabriele Bavota Denys Poshyvanyk},
doi = {10.1109/ICSE.2019.00021},
journal = {Proceedings of the 41st International Conference on Software Engineering},
keywords = {,empirical study,neural-machine translation},
pages = {25--36},
publisher = {IEEE Press},
series = {ICSE '19},
title = {{On Learning Meaningful Code Changes via Neural Machine Translation}},
url = {https://doi.org/10.1109/ICSE.2019.00021},
year = {2019}
}
@article{DBLP:journals/infsof/HuZCYYW19,
author = {Hu, Dongyang and Zhang, Yang and Chang, Junsheng and Yin, Gang and Yu, Yue and Wang, Tao},
doi = {10.1016/j.infsof.2019.07.004},
journal = {Inf. Softw. Technol.},
pages = {1--4},
title = {{Multi-reviewing pull-requests: An exploratory study on GitHub {\{}OSS{\}} projects}},
url = {https://doi.org/10.1016/j.infsof.2019.07.004},
volume = {115},
year = {2019}
}
@article{10.1007/s10664-019-09788-5,
author = {Shihab, Ahmad AbdellatifKhaled BadranEmad},
doi = {10.1007/s10664-019-09788-5},
journal = {Empirical Software Engineering},
number = {3},
title = {{MSRBot: Using bots to answer questions from software repositories}},
url = {http://link.springer.com/article/10.1007/s10664-019-09788-5},
volume = {25},
year = {2020}
}
@inproceedings{10.1145/2652524.2652549,
abstract = {Context: Not releasing software on time can cause substantial loss in revenue. Continuous awareness of the product release status is required. Release readiness is a time-dependent attribute of the status of the product release, which aggregates the degree of satisfaction of a portfolio of release process and product measures.Goal: At different stages of a release cycle, the goal is to understand frequencies and pattern of occurrence of factors affecting project success by restricting the status of release readiness (called bottlenecks).Method: As a form of explorative case study research, we analyzed ten open source software (OSS) projects taken from the GitHub repository. As a retrospective study covering a period of 28 weeks, we monitored eight release readiness attributes and identified their impact on release readiness over time across the ten projects.Results: Feature completion rate, Bug fixing rate, and Features implemented were observed as the most frequent bottlenecks. The most frequent transition between bottlenecks is from Pull-request completion rate to Bug fixing rate. With the exception of Pull-request completion rate, no significant differences were found in occurrence of bottleneck factors between early and late stage of the release cycle.Conclusions: We received an initial understanding of the most frequent bottleneck factors for release readiness and their likelihood of subsequent occurrence. This is intended to guide the effort spent on improving release engineering.},
address = {New York, NY, USA},
author = {{Al Alam}, S M Didar and Shahnewaz, S M and Pfahl, Dietmar and Ruhe, Guenther},
booktitle = {Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement},
doi = {10.1145/2652524.2652549},
isbn = {9781450327749},
keywords = { bottleneck identification, exploratory case study, retrospective analysis,release readiness},
publisher = {Association for Computing Machinery},
series = {ESEM '14},
title = {{Monitoring Bottlenecks in Achieving Release Readiness: A Retrospective Case Study across Ten OSS Projects}},
url = {https://doi.org/10.1145/2652524.2652549},
year = {2014}
}
@article{Viviani2019,
abstract = {A software system's design determines many of its properties, such as maintainability and performance. An understanding of design is needed to maintain system properties as changes to the system occur. Unfortunately, many systems do not have up-to-date design documentation and approaches that have been developed to recover design often focus on how a system works by extracting structural and behaviour information rather than information about the desired design properties, such as robustness or performance. In this paper, we explore whether it is possible to automatically locate where design is discussed in on-line developer discussions. We investigate and introduce a classifier that can locate paragraphs in pull request discussions that pertain to design with an average AUC score of 0.87. We show that this classifier agrees with human developers in 81{\%} of cases considered. To show how the location of latent design information in developer discussions is useful, we present a proof-of-concept tool that can identify design concerns automatically from the identified design discussions and describe how this extracted design information might be provided to developers.},
author = {Viviani, G and Famelis, M and Xia, X and Janik-Jones, C and Murphy, G C},
doi = {10.1109/TSE.2019.2924006},
issn = {1939-3520 VO -},
journal = {IEEE Transactions on Software Engineering},
keywords = {Conversations,Design Discussions,Design Recovery,Documentation,Latent Design,Prediction Model,Predictive models,Robustness,Software systems,System analysis and design,Tools},
pages = {1},
title = {{Locating Latent Design Information in Developer Discussions: A Study on Pull Requests}},
year = {2019}
}
@inproceedings{10.1145/2635868.2635882,
abstract = { Open source software projects often rely on code contributions from a wide variety of developers to extend the capabilities of their software. Project members evaluate these contributions and often engage in extended discussions to decide whether to integrate changes. These discussions have important implications for project management regarding new contributors and evolution of project requirements and direction. We present a study of how developers in open work environments evaluate and discuss pull requests, a primary method of contribution in GitHub, analyzing a sample of extended discussions around pull requests and interviews with GitHub developers. We found that developers raised issues around contributions over both the appropriateness of the problem that the submitter attempted to solve and the correctness of the implemented solution. Both core project members and third-party stakeholders discussed and sometimes implemented alternative solutions to address these issues. Different stakeholders also influenced the outcome of the evaluation by eliciting support from different communities such as dependent projects or even companies. We also found that evaluation outcomes may be more complex than simply acceptance or rejection. In some cases, although a submitter's contribution was rejected, the core team fulfilled the submitter's technical goals by implementing an alternative solution. We found that the level of a submitter's prior interaction on a project changed how politely developers discussed the contribution and the nature of proposed alternative solutions. },
address = {New York, NY, USA},
author = {Tsay, Jason and Dabbish, Laura and Herbsleb, James},
booktitle = {Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering},
doi = {10.1145/2635868.2635882},
isbn = {9781450330565},
keywords = { GitHub, contribution, discussion, evaluation, open source, social media, transparency,social computing},
pages = {144--154},
publisher = {Association for Computing Machinery},
series = {FSE 2014},
title = {{Let's Talk about It: Evaluating Contributions through Discussion in GitHub}},
url = {https://doi.org/10.1145/2635868.2635882},
year = {2014}
}
@article{Ye2019,
abstract = {In pull-based software development, anyone who wants to contribute to a project can request integration of the code changes to the public repository by sending a pull request to the development team. Upon receiving a pull request, a team member will review the changes and decide on merging it or not in the repository. Finding the appropriate reviewer for a pull request is a crucial step. To support reviewer recommendation, this paper introduces an adaptive ranking model to rank all the reviewer candidates for a pull request. The ranking model leverages 14 features to measure the relationships between a pull request and the reviewer candidates. The weight parameters of the ranking model are trained automatically based on previously resolved pull requests by using a learning-to-rank technique. The experimental evaluations on 12 open-source projects show that the proposed approach outperforms the baseline and a state-of-the-art approach. It can recommend the suitable reviewers within top-1 recommendation for over 80{\%} of the pull requests in the opencv and jekyll projects. The feature selection experiments show that the most important feature is the feature that counts the number of previous pull requests sent by the requester and reviewed by a developer. The feature that measures the file path similarity between files changed in the pull request and files previously modified by a developer is another important feature.},
author = {Ye, X},
doi = {10.1109/ACCESS.2019.2925560},
issn = {2169-3536 VO - 7},
journal = {IEEE Access},
keywords = {Adaptation models,Feature extraction,Learning to rank,Mathematical model,Micromechanical devices,Open source software,Support vector machines,adaptive ranking model,feature extraction,feature selection,learning (artificial intelligence),learning-to-rank technique,public domain software,pull request,pull-based software development,reviewer candidates,reviewer recommendation,software engineering},
pages = {85382--85391},
title = {{Learning to Rank Reviewers for Pull Requests}},
volume = {7},
year = {2019}
}
@article{arXiv:1803.03806,
abstract = {Abstract: Code analyzers such as Error Prone and FindBugs detect code patterns symptomatic of bugs, performance issues, or bad style. These tools express patterns as quick fixes that detect and rewrite unwanted code. However, it is difficult to come up with new quick fixes and decide which ones are useful and frequently appear in real code. We propose to rely on the collective wisdom of programmers and learn quick fixes from revision histories in software repositories. We present REVISAR, a tool for discovering common Java edit patterns in code repositories. Given code repositories and their revision histories, REVISAR (i) identifies code edits from revisions and (ii) clusters edits into sets that can be described using an edit pattern. The designers of code analyzers can then inspect the patterns and add the corresponding quick fixes to their tools. We ran REVISAR on nine popular GitHub projects, and it discovered 89 useful edit patterns that appeared in 3 or more projects. Moreover, 64{\%} of the discovered patterns did not appear in existing tools. We then conducted a survey with 164 programmers from 124 projects and found that programmers significantly preferred eight out of the nine of the discovered patterns. Finally, we submitted 16 pull requests applying our patterns to 9 projects and, at the time of the writing, programmers accepted 6 (60{\%}) of them. The results of this work aid toolsmiths in discovering quick fixes and making informed decisions about which quick fixes to prioritize based on patterns programmers actually apply in practice. △ Less},
author = {{Authors: Reudismam Rolim Gustavo Soares}, Rohit Gheyi Titus Barik Loris D'Antoni},
journal = {arXiv preprint arXiv:1803.03806},
title = {{Learning Quick Fixes from Code Repositories}},
year = {2018}
}
@inproceedings{10.1145/2597073.2597126,
abstract = { In recent years, GitHub has become the largest code host in the world, with more than 5M developers collaborating across 10M repositories. Numerous popular open source projects (such as Ruby on Rails, Homebrew, Bootstrap, Django or jQuery) have chosen GitHub as their host and have migrated their code base to it. GitHub offers a tremendous research potential. For instance, it is a flagship for current open source development, a place for developers to showcase their expertise to peers or potential recruiters, and the platform where social coding features or pull requests emerged. However, GitHub data is, to date, largely underexplored. To facilitate studies of GitHub, we have created GHTorrent, a scalable, queriable, offline mirror of the data offered through the GitHub REST API. In this paper we present a novel feature of GHTorrent designed to offer customisable data dumps on demand. The new GHTorrent data-on-demand service offers users the possibility to request via a web form up-to-date GHTorrent data dumps for any collection of GitHub repositories. We hope that by offering customisable GHTorrent data dumps we will not only lower the "barrier for entry" even further for researchers interested in mining GitHub data (thus encourage researchers to intensify their mining efforts), but also enhance the replicability of GitHub studies (since a snapshot of the data on which the results were obtained can now easily accompany each study). },
address = {New York, NY, USA},
author = {Gousios, Georgios and Vasilescu, Bogdan and Serebrenik, Alexander and Zaidman, Andy},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
doi = {10.1145/2597073.2597126},
isbn = {9781450328630},
keywords = { GitHub, dataset,data on demand},
pages = {384--387},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{Lean GHTorrent: GitHub Data on Demand}},
url = {https://doi.org/10.1145/2597073.2597126},
year = {2014}
}
@article{10.1007/s13748-019-00182-2,
author = {Marticorena-S{\'{a}}nchez, Jes{\'{u}}s M Alonso-AbadCarlos L{\'{o}}pez-NozalJes{\'{u}}s M Maudes-RaedoRa{\'{u}}l},
doi = {10.1007/s13748-019-00182-2},
journal = {Progress in Artificial Intelligence},
number = {3},
title = {{Label prediction on issue tracking systems using text mining}},
url = {http://link.springer.com/article/10.1007/s13748-019-00182-2},
volume = {8},
year = {2019}
}
@inproceedings{10.1145/3350768.3351800,
abstract = {The advent of open source has changed the way developers reuse software. The availability of libraries and their corresponding source code in public software repositories enables new forms of analyzing project aspects that can provide clues on their stability and maintainability. However, the literature lacks studies aiming to identify and understand whether and which repository features may correlate with the likeliness of usage of a library. In this sense, we present a factorial experiment using three different regression models - Multiple Linear Regression, Random Forest, and Neural Networks -, aiming at analyzing whether there is a correlation between library usage and a set of features extracted from release management and version control repositories. The results allowed to map features with positive learning impact, such as the number of stars, pull requests, and number of downloads, as well as features that contributed much less to the models (e.g., the repository size). Although the impact level of each feature varied from model to model, we also noticed from the analysis of regression results that the models were capable of achieving higher accuracy when considering only a subset of features.Paper category: Experimental; Language: English},
address = {New York, NY, USA},
author = {Esteves, Jo{\~{a}}o Victor and Coutinho, Daniel and Schots, Marcelo and Coelho, Igor Machado},
booktitle = {Proceedings of the XXXIII Brazilian Symposium on Software Engineering},
doi = {10.1145/3350768.3351800},
isbn = {9781450376518},
keywords = { library usage, mining software repositories, software reuse,Regression models},
pages = {407--416},
publisher = {Association for Computing Machinery},
series = {SBES 2019},
title = {{Is There an Interplay Between Library Usage and Repository Features? An Analysis with Regression Models}},
url = {https://doi.org/10.1145/3350768.3351800},
year = {2019}
}
@article{10.1007/s10664-019-09703-y,
author = {Tsantalis, Sara Seif AfjeheiTse-Hsun (Peter) ChenNikolaos},
doi = {10.1007/s10664-019-09703-y},
journal = {Empirical Software Engineering},
number = {6},
title = {{iPerfDetector: Characterizing and detecting performance anti-patterns in iOS applications}},
url = {http://link.springer.com/article/10.1007/s10664-019-09703-y},
volume = {24},
year = {2019}
}
@misc{zhang2014investigating,
author = {Zhang, Y and Yin, G and Yu, Y and Wang, H},
title = {{Investigating social media in GitHub's pull-requests: a case study on Ruby on Rails}},
year = {2014}
}
@inproceedings{10.1145/2666539.2666572,
abstract = { In GitHub, pull-request mechanism is an outstanding social development method by integrating with many social media. Many studies have explored that social media has an important effect on software development. @-mention as a typical social media, is a useful tool in social platform. In this paper, we made a quantitative analysis of @-mention in pull-requests of the project Ruby on Rails. First, we make a convictive statistics of the popularity of pull-request mechanism in GitHub. Then we investigate the current situation of @-mention in the Ruby on Rails. Our empirical analysis results find some insights of @-mention. },
address = {New York, NY, USA},
author = {Zhang, Yang and Yin, Gang and Yu, Yue and Wang, Huaimin},
booktitle = {Proceedings of the 1st International Workshop on Crowd-Based Software Development Methods and Technologies},
doi = {10.1145/2666539.2666572},
isbn = {9781450332248},
keywords = { @-mention, GitHub, pull-request,Social media},
pages = {37--41},
publisher = {Association for Computing Machinery},
series = {CrowdSoft 2014},
title = {{Investigating Social Media in GitHub's Pull-Requests: A Case Study on Ruby on Rails}},
url = {https://doi.org/10.1145/2666539.2666572},
year = {2014}
}
@phdthesis{rathnayake2019interec,
abstract = {Over the last decade, open source software development, dramatically changed with the introduction of the pull-based development mechanism. The pull-based method became popular because of the convenience for collaborative contributions. With the introduction of pull-based development in the distributed software development, the number of contributions received for projects has risen as this method lowered the entry barrier for contributions. Nowadays social coding platforms such as GitHub, GitLab and Bitbucket, integrated this pullbased model in their platforms. Due to the rising number of contributions received for pullbased development platforms via pull-requests, the people (integrators) who decide to accept or reject the pull-requests, faced difficulty in managing the pull-requests. As a result of that, it is observed that a significant delay occured in accepting or rejecting a pull-request. In order to address this issue, integrator recommendation systems were introduced to recommend appropriate integrators to review pull-requests. This research focuses on providing a solution for the difficulty mentioned above, faced by the integrators. The existing solutions have used three main traditional approaches to recommend integrators. File path similarity calculation, similarity calculation for the textual content of the PR and integrator activeness calculation are the three main approaches. In this research, an algorithm was designed to combine these three traditional approaches and create a novel hybrid solution. Furthermore, research was conducted to find the optimal date limit when using the past PR data to recommend integrators for pull-requests. The solution, InteRec achieves an average of 83{\%} accuracy in terms of Top-3 accuracy and outperforms the traditional approaches.},
author = {Rathnayake, Raveen Savinda},
title = {{InteRec-Integrator Recommendation for Pull-Based Distributed Software Development}},
url = {http://dlib.iit.ac.lk/xmlui/handle/123456789/308},
year = {2019}
}
@inproceedings{8930873,
abstract = {The documentation of code changes is significantly important but developers ignore it, most of the time, due to the pressure of the deadlines. While developers may document the most important features modification or bugs fixing, recent empirical studies show that the documentation of quality improvements and/or refactoring is often omitted or not accurately described. However, the automated or semi-automated documentation of refactorings has not been yet explored despite the extensive work on the remaining steps of refactoring including the detection, prioritization and recommendation. In this paper, we propose a semi-automated refactoring documentation bot that helps developers to interactively check and validate the documentation of the refactorings and/or quality improvements at the file level for each opened pull-request before being reviewed or merged to the master. The bot starts by checking the pullrequest if there are significant quality changes and refactorings at the file level and whether they are documented by the developer. Then, it checks the validity of the developers description of the refactorings, if any. Based on that analysis, the documentation bot will recommend a message to document the refactorings, their locations and the quality improvement for that pull-request when missing information is found. Then, the developer can modify his pull request description by interacting with the bot to accept/modify/reject part of the proposed documentation. Since refactoring do not happen in isolation most of the time, the bot is documenting the impact of a sequence of refactorings, in a pull-request, on quality and not each refactoring in isolation. We conducted a human survey with 14 active developers to manually evaluate the relevance and the correctness of our tool on different pull requests of 5 open source projects and one industrial system. The results show that the participants found that our bot facilitates the documentation of their quality-related changes and refactorings.},
author = {Rebai, S and {Ben Sghaier}, O and Alizadeh, V and Kessentini, M and Chater, M},
booktitle = {2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM)},
doi = {10.1109/SCAM.2019.00026},
issn = {2470-6892},
keywords = {program debugging;public domain software;software maintenance;software quality;quality improvement;interactive refactoring documentation bot;semi-automated refactoring documentation bot;file level;pull-request description;open source projects;industrial system;quality-related changes;Documentation;Measurement;Feature extraction;Tools;Software;Couplings;Security;Intelligent bot;refactoring;documentation},
pages = {152--162},
title = {{Interactive Refactoring Documentation Bot}},
year = {2019}
}
@inproceedings{7335397,
abstract = {Continuous integration of source code changes, for example, via pull-request driven contribution channels, has become standard in many software projects. However, the decision to integrate source code changes into a release is complex and has to be taken by a software manager. In this work, we identify a set of three pragmatic recipes plus variations to support the decision making of integrating code contributions into a release. These recipes cover the isolation of source code changes, contribution of test code, and the linking of commits to issues. We analyze the development history of 21 open-source software projects, to evaluate whether, and to what extent, those recipes are followed in open-source projects. The results of our analysis showed that open-source projects largely follow recipes on a compliance level of {\textgreater} 75{\%}. Hence, we conclude that the identified recipes plus variations can be seen as wide-spread relevant best-practices for source code integration.},
author = {Brandtner, M and Leitner, P and Gall, H C},
booktitle = {2015 IEEE 15th International Working Conference on Source Code Analysis and Manipulation (SCAM)},
doi = {10.1109/SCAM.2015.7335397},
keywords = {decision making;program testing;project management;public domain software;source code (software);intent;release dependency;pragmatic recipe;source code integration;decision making;source code change isolation;test code contribution;open-source software projects;Interviews;Open source software;Companies;Guidelines;Pragmatics;Lead},
pages = {11--20},
title = {{Intent, tests, and release dependencies: Pragmatic recipes for source code integration}},
year = {2015}
}
@inproceedings{10.1109/MSR.2017.30,
abstract = {Continuous integration is prevalently used in modern software engineering to build software systems automatically. Broken builds hinder developers' work and delay project progress. We must identify the factors causing build failures.This paper presents a large empirical study to identify the factors such as, complexity of a task, build strategy and contribution models (i.e., push and pull request), and projects level attributes (i.e., sizes of projects and teams), which potentially have impacts on the build results. We have studied 3.6 million builds over 1,090 open-source projects. The derived results add to our understanding of the role of those factors on build results, which can be used in minimizing build failures.},
author = {Islam, Md Rakibul and Zibran, Minhaz F},
booktitle = {Proceedings of the 14th International Conference on Mining Software Repositories},
doi = {10.1109/MSR.2017.30},
isbn = {9781538615447},
pages = {467--470},
publisher = {IEEE Press},
series = {MSR '17},
title = {{Insights into Continuous Integration Build Failures}},
url = {https://doi.org/10.1109/MSR.2017.30},
year = {2017}
}
@article{arXiv:1606.00521,
abstract = {Abstract: The constant demand for new features and bug fixes are forcing software projects to shorten cycles and deliver updates ever faster, while sustaining software quality. The availability of inexpensive, virtualized, cloud-computing has helped shorten schedules, by enabling continuous integration (CI) on demand. Platforms like GitHub support CI in-the-cloud. In projects using CI, a user submitting a pull request triggers a CI step. Besides speeding up build and test, this fortuitously creates voluminous archives of build and test successes and failures. CI is a relatively new phenomenon, and these archives allow a detailed study of CI. How many problems are exposed? Where do they occur? What factors affect CI failures? Does the "initial quality" as ascertained by CI predict how many bugs will later appear ("eventual quality") in the code? In this paper, we undertake a large-scale, fine resolution study of these records, to better understand CI processes, the nature, and predictors of CI failures, and the relationship of CI failures to the eventual quality of the code. We find that: a) CI failures appear to be concentrated in a few files, just like normal bugs; b) CI failures are not very highly correlated with eventual failures; c) The use of CI in a pull request doesn't necessarily mean the code in that request is of good quality. △ Less},
author = {{Authors: Yue Yu Bogdan Vasilescu}, Huaimin Wang Vladimir Filkov Premkumar Devanbu},
journal = {arXiv preprint arXiv:1606.00521},
title = {{Initial and Eventual Software Quality Relating to Continuous Integration in GitHub}},
year = {2016}
}
@inproceedings{10.1145/2568225.2568315,
abstract = { Open source software is commonly portrayed as a meritocracy, where decisions are based solely on their technical merit. However, literature on open source suggests a complex social structure underlying the meritocracy. Social work environments such as GitHub make the relationships between users and between users and work artifacts transparent. This transparency enables developers to better use information such as technical value and social connections when making work decisions. We present a study on open source software contribution in GitHub that focuses on the task of evaluating pull requests, which are one of the primary methods for contributing code in GitHub. We analyzed the association of various technical and social measures with the likelihood of contribution acceptance. We found that project managers made use of information signaling both good technical contribution practices for a pull request and the strength of the social connection between the submitter and project manager when evaluating pull requests. Pull requests with many comments were much less likely to be accepted, moderated by the submitter's prior interaction in the project. Well-established projects were more conservative in accepting pull requests. These findings provide evidence that developers use both technical and social information when evaluating potential contributions to open source software projects. },
address = {New York, NY, USA},
author = {Tsay, Jason and Dabbish, Laura and Herbsleb, James},
booktitle = {Proceedings of the 36th International Conference on Software Engineering},
doi = {10.1145/2568225.2568315},
isbn = {9781450327565},
keywords = { GitHub, contribution, open source, signaling theory, social computing, social media,transparency},
pages = {356--366},
publisher = {Association for Computing Machinery},
series = {ICSE 2014},
title = {{Influence of Social and Technical Factors for Evaluating Contribution in GitHub}},
url = {https://doi.org/10.1145/2568225.2568315},
year = {2014}
}
@article{10.1007/s10515-017-0227-0,
author = {Hunsen, Olaf Le{\ss}enichJanet SiegmundSven ApelChristian K{\"{a}}stnerClaus},
doi = {10.1007/s10515-017-0227-0},
journal = {Automated Software Engineering},
number = {2},
title = {{Indicators for merge conflicts in the wild: survey and empirical study}},
url = {http://link.springer.com/article/10.1007/s10515-017-0227-0},
volume = {25},
year = {2018}
}
@article{10.1007/s10664-019-09696-8,
author = {{da CostaYing Zou}, Guoliang ZhaoDaniel Alencar and Zhao, Guoliang and da Costa, Daniel Alencar and Zou, Ying},
doi = {10.1007/s10664-019-09696-8},
journal = {Empir. Softw. Eng.},
number = {4},
pages = {2140--2170},
title = {{Improving the pull requests review process using learning-to-rank algorithms}},
url = {https://doi.org/10.1007/s10664-019-09696-8 http://link.springer.com/article/10.1007/s10664-019-09696-8},
volume = {24},
year = {2019}
}
@article{10.1007/s11704-019-9023-2,
author = {Li, Yao LuXinjun MaoTao WangGang YinZude},
doi = {10.1007/s11704-019-9023-2},
journal = {Frontiers of Computer Science},
number = {5},
title = {{Improving students' programming quality with the continuous inspection process: a social coding perspective}},
url = {http://link.springer.com/article/10.1007/s11704-019-9023-2},
volume = {14},
year = {2020}
}
@inproceedings{10.1109/ASE.2019.00144,
abstract = {Fork-based development is a lightweight mechanism that allows developers to collaborate with or without explicit coordination. Although it is easy to use and popular, when developers each create their own fork and develop independently, their contributions are usually not easily visible to others. When the number of forks grows, it becomes very difficult to maintain an overview of what happens in individual forks, which would lead to additional problems and inefficient practices: lost contributions, redundant development, fragmented communities, and so on. Facing the problems mentioned above, we developed two complementary strategies: (1) Identifying existing best practices and suggesting evidence-based interventions for projects that are inefficient; (2) designing new interventions that could improve the awareness of a community using fork-based development, and help developers to detect redundant development to reduce unnecessary effort.},
author = {Zhou, Shurui},
booktitle = {Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering},
doi = {10.1109/ASE.2019.00144},
isbn = {9781728125084},
keywords = { awareness of collaboration, distributed collaboration, fork-based development,open-source community},
pages = {1218--1221},
publisher = {IEEE Press},
series = {ASE '19},
title = {{Improving Collaboration Efficiency in Fork-Based Development}},
url = {https://doi.org/10.1109/ASE.2019.00144},
year = {2019}
}
@inproceedings{10.1109/MSR.2017.39,
abstract = {Peer code review and continuous integration often interleave with each other in the modern software quality management. Although several studies investigate how non-technical factors (e.g., reviewer workload), developer participation and even patch size affect the code review process, the impact of continuous integration on code reviews is not yet properly understood. In this paper, we report an exploratory study using 578K automated build entries where we investigate the impact of automated builds on the code reviews. Our investigation suggests that successfully passed builds are more likely to encourage new code review participation in a pull request. Frequently built projects are found to be maintaining a steady level of reviewing activities over the years, which was quite missing from the rarely built projects. Experiments with 26,516 automated build entries reported that our proposed model can identify 64{\%} of the builds that triggered new code reviews later.},
author = {Rahman, Mohammad Masudur and Roy, Chanchal K},
booktitle = {Proceedings of the 14th International Conference on Mining Software Repositories},
doi = {10.1109/MSR.2017.39},
isbn = {9781538615447},
pages = {499--502},
publisher = {IEEE Press},
series = {MSR '17},
title = {{Impact of Continuous Integration on Code Reviews}},
url = {https://doi.org/10.1109/MSR.2017.39},
year = {2017}
}
@article{10.1007/s11280-019-00770-1,
author = {Wang, Yang ZhangYiwen WuTao WangHuaimin},
doi = {10.1007/s11280-019-00770-1},
journal = {World Wide Web},
number = {3},
title = {{iLinker: a novel approach for issue knowledge acquisition in GitHub projects}},
url = {http://link.springer.com/article/10.1007/s11280-019-00770-1},
volume = {23},
year = {2020}
}

687
experiment/study-search/papers-3.bib Normal file
View File

@ -0,0 +1,687 @@
@inproceedings{10.1145/3338906.3338925,
abstract = {Regression testing provides important pass or fail signals that developers use to make decisions after code changes. However, flaky tests, which pass or fail even when the code has not changed, can mislead developers. A common kind of flaky tests are order-dependent tests, which pass or fail depending on the order in which the tests are run. Fixing order-dependent tests is often tedious and time-consuming. We propose iFixFlakies, a framework for automatically fixing order-dependent tests. The key insight in iFixFlakies is that test suites often already have tests, which we call helpers, whose logic resets or sets the states for order-dependent tests to pass. iFixFlakies searches a test suite for helpers that make the order-dependent tests pass and then recommends patches for the order-dependent tests using code from these helpers. Our evaluation on 110 truly orderdependent tests from a public dataset shows that 58 of them have helpers, and iFixFlakies can fix all 58. We opened pull requests for 56 order-dependent tests (2 of 58 were already fixed), and developers have already accepted pull requests for 21 of them, with all the remaining ones still pending.},
address = {New York, NY, USA},
author = {Shi, August and Lam, Wing and Oei, Reed and Xie, Tao and Marinov, Darko},
booktitle = {Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering},
doi = {10.1145/3338906.3338925},
isbn = {9781450355728},
keywords = { automated fixing, order-dependent test, patch generation,flaky test},
pages = {545--555},
publisher = {Association for Computing Machinery},
series = {ESEC/FSE 2019},
title = {{IFixFlakies: A Framework for Automatically Fixing Order-Dependent Flaky Tests}},
url = {https://doi.org/10.1145/3338906.3338925},
year = {2019}
}
@inproceedings{10.1145/3239235.3240501,
abstract = {Background: Open source software has an increasing importance in modern software development. However, there is also a growing concern on the sustainability of such projects, which are usually managed by a small number of developers, frequently working as volunteers. Aims: In this paper, we propose an approach to identify GitHub projects that are not actively maintained. Our goal is to alert users about the risks of using these projects and possibly motivate other developers to assume the maintenance of the projects. Method: We train machine learning models to identify unmaintained or sparsely maintained projects, based on a set of features about project activity (commits, forks, issues, etc). We empirically validate the model with the best performance with the principal developers of 129 GitHub projects. Results: The proposed machine learning approach has a precision of 80{\%}, based on the feedback of real open source developers; and a recall of 96{\%}. We also show that our approach can be used to assess the risks of projects becoming unmaintained. Conclusions: The model proposed in this paper can be used by open source users and developers to identify GitHub projects that are not actively maintained anymore.},
address = {New York, NY, USA},
author = {Coelho, Jailton and Valente, Marco Tulio and Silva, Luciana L and Shihab, Emad},
booktitle = {Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement},
doi = {10.1145/3239235.3240501},
isbn = {9781450358231},
keywords = { github, open source software,unmaintained projects},
publisher = {Association for Computing Machinery},
series = {ESEM '18},
title = {{Identifying Unmaintained Projects in Github}},
url = {https://doi.org/10.1145/3239235.3240501},
year = {2018}
}
@inproceedings{DBLP:conf/wcre/RenZKW19,
author = {Ren, Luyao and Zhou, Shurui and K{\"{a}}stner, Christian and Wasowski, Andrzej},
booktitle = {26th {\{}IEEE{\}} International Conference on Software Analysis, Evolution and Reengineering, {\{}SANER{\}} 2019, Hangzhou, China, February 24-27, 2019},
doi = {10.1109/SANER.2019.8668023},
editor = {Wang, Xinyu and Lo, David and Shihab, Emad},
pages = {230--241},
publisher = {IEEE},
title = {{Identifying Redundancies in Fork-based Development}},
url = {https://doi.org/10.1109/SANER.2019.8668023},
year = {2019}
}
@inproceedings{8987552,
abstract = {Bugs are inevitable in software development and maintenance processes. Recently a lot of research efforts have been devoted to automatic program repair, aiming to reduce the efforts of debugging. However, since it is difficult to ensure that the generated patches meet all quality requirements such as correctness, developers still need to review the patch. In addition, current techniques produce only patches without explanation, making it difficult for the developers to understand the patch. Therefore, we believe a more desirable approach should generate not only the patch but also an explanation of the patch. To generate a patch explanation, it is important to first understand how patches were explained. In this paper, we explored how developers explain their patches by manually analyzing 300 merged bug-fixing pull requests from six projects on GitHub. Our contribution is twofold. First, we build a patch explanation model, which summarizes the elements in a patch explanation, and corresponding expressive forms. Second, we conducted a quantitative analysis to understand the distributions of elements, and the correlation between elements and their expressive forms.},
author = {Liang, J and Hou, Y and Zhou, S and Chen, J and Xiong, Y and Huang, G},
booktitle = {2019 IEEE 30th International Symposium on Software Reliability Engineering (ISSRE)},
doi = {10.1109/ISSRE.2019.00016},
issn = {2332-6549},
keywords = { bug-fixing, explanation, program repair,automatic programming;program debugging;public domain software;software maintenance;GitHub;merged bug-fixing pull requests;automatic program repair;program debugging;software maintenance process;software development;open source projects;patch explanation model;patch},
pages = {58--69},
title = {{How to Explain a Patch: An Empirical Study of Patch Explanations in Open Source Projects}},
year = {2019}
}
@article{quick2014long,
author = {Quick, Bronson},
publisher = {Sennza},
title = {{How Long Does An Eight Line Pull Request Take?}},
year = {2014}
}
@inproceedings{10.1109/MSR.2017.32,
abstract = {The recent introduction of the pull-based development model promoted agile development practices such as Code Reviews and Continuous Integration (CI). CI, in particular, is currently a standard development practice in open-source software (OSS) projects. Although it is well-known that OSS contributors have different involvements (e.g., while some developers drive the project, there is a long tail of peripheral developers), little is known about how the contributor's degree of participation can influence the build status of an OSS project. Through TravisTorrent's dataset, we compare the success rates of builds made by casual and non-casual contributors and what factors on their contributions may influence the build result. Our results suggest that there is no representative difference between their build success (they are similar in 85{\%} of the analyzed projects), meaning that being a casual contributor is not a strong indicator for creating failing builds. Also, factors like the size of their contributions and the number of project configurations (jobs) have the potential of impacting the build success.},
author = {Rebou{\c{c}}as, Marcel and Santos, Renato O and Pinto, Gustavo and Castor, Fernando},
booktitle = {Proceedings of the 14th International Conference on Mining Software Repositories},
doi = {10.1109/MSR.2017.32},
isbn = {9781538615447},
pages = {475--478},
publisher = {IEEE Press},
series = {MSR '17},
title = {{How Does Contributors' Involvement Influence the Build Status of an Open-Source Software Project?}},
url = {https://doi.org/10.1109/MSR.2017.32},
year = {2017}
}
@article{DBLP:journals/ese/ZouXXCX19,
author = {Zou, Weiqin and Xuan, Jifeng and Xie, Xiaoyuan and Chen, Zhenyu and Xu, Baowen},
doi = {10.1007/s10664-019-09720-x},
journal = {Empir. Softw. Eng.},
number = {6},
pages = {3871--3903},
title = {{How does code style inconsistency affect pull request integration? An exploratory study on 117 GitHub projects}},
url = {https://doi.org/10.1007/s10664-019-09720-x},
volume = {24},
year = {2019}
}
@article{DBLP:journals/access/OrtuDGMT20,
author = {Ortu, Marco and Destefanis, Giuseppe and Graziotin, Daniel and Marchesi, Michele and Tonelli, Roberto},
doi = {10.1109/ACCESS.2020.3002663},
journal = {{\{}IEEE{\}} Access},
pages = {110897--110907},
title = {{How do you Propose Your Code Changes? Empirical Analysis of Affect Metrics of Pull Requests on GitHub}},
url = {https://doi.org/10.1109/ACCESS.2020.3002663},
volume = {8},
year = {2020}
}
@inproceedings{8305987,
abstract = {Concurrent programming is pervasive in nowadays software development. Many programmers believe that concurrent programming is difficult, and maintaining concurrency code is error-prone. Although researchers have conducted empirical studies to understand concurrent programming, they still rarely study how programmers maintain concurrent code. To the best of our knowledge, only a recent study explored the modifications on critical sections, and many related questions are still open. In this paper, we conduct an empirical study to explore how programmers maintain concurrent code. We analyze more concurrency-related commits and explore more issues such as the change patterns of maintaining concurrent code than the previous study. We summarize five change patterns according to our analysis on 696 concurrency-related commits. We apply our change patterns to three open source projects, and synthesize three pull requests. Until now, two of them have been accepted. Our results can be useful for programmers to maintain concurrent code and for researchers to implement treating techniques.},
author = {Yu, F and Zhong, H and Shen, B},
booktitle = {2017 24th Asia-Pacific Software Engineering Conference (APSEC)},
doi = {10.1109/APSEC.2017.71},
keywords = {concurrency control;program debugging;software maintenance;programmers;concurrent code;concurrent programming;concurrency code;software development;concurrency-related commits;bug fixes;concurrency control mechanism;Tools;Synchronization;Computer bugs;Programming;Manuals;Concurrent computing;Software;Maintenance;Concurrency;Pattern},
pages = {594--599},
title = {{How Do Programmers Maintain Concurrent Code?}},
year = {2017}
}
@inproceedings{DBLP:conf/wcre/SaitoFIYI16,
author = {Saito, Yusuke and Fujiwara, Kenji and Igaki, Hiroshi and Yoshida, Norihiro and Iida, Hajimu},
booktitle = {7th International Workshop on Empirical Software Engineering in Practice, IWESEP@SANER 2016, Osaka, Japan, March 13, 2016},
doi = {10.1109/IWESEP.2016.19},
pages = {7--11},
publisher = {{\{}IEEE{\}} Computer Society},
title = {{How do GitHub Users Feel with Pull-Based Development?}},
url = {https://doi.org/10.1109/IWESEP.2016.19},
year = {2016}
}
@inproceedings{10.1145/3383219.3383242,
abstract = {Pull requests are a method to facilitate review and management of contribution in distributed software development. Software developers author commits, and present them in a pull request to be inspected by maintainers and reviewers. The success and sustainability of communities depends on ongoing contributions, but rejections decrease motivation of contributors. We carried out a a qualitative study to understand the mechanisms of evaluating PRs in open source software (FOSS) communities from developers and maintainers perspective. We interviewed 30 participants from five different FOSS communities. The data shows that acceptance of contributions depends not only on technical criteria, but also significantly on social and strategic aspects. This paper identifies three PR governance styles found in the studied communities: (1) protective, (2) equitable and (3) lenient. Each one of these styles has its particularities. While the protective style values trustworthiness and reliability of the contributor, the lenient style believes in creating a positive and welcoming environment where contributors are mentored to evolve contributions until they meet the community standards. Despite the differences, these governance styles have a commonality, they all safeguard the quality of the software.},
address = {New York, NY, USA},
author = {Alami, Adam and Cohn, Marisa Leavitt and W$\backslash$kaisowski, Andrzej},
booktitle = {Proceedings of the Evaluation and Assessment in Software Engineering},
doi = {10.1145/3383219.3383242},
isbn = {9781450377317},
keywords = { Open source software, code review, community management, decision making, pull request,FOSS governance},
pages = {220--229},
publisher = {Association for Computing Machinery},
series = {EASE '20},
title = {{How Do FOSS Communities Decide to Accept Pull Requests?}},
url = {https://doi.org/10.1145/3383219.3383242},
year = {2020}
}
@article{10.1186/s40411-017-0044-y,
abstract = {Background: Building an effective team of developers is a complex task faced by both software companies and open source communities. The problem of forming a “dream” team involves many variables, including consideration of human factors and it is not a dilemma solvable in a mathematical way. Empirical studies might provide interesting insights to explain which factors need to be taken into account in building a team of developers and which levers act to optimise productivity among developers. Aim: In this paper, we present the results of an empirical study aimed at investigating the link between team diversity (i.e., gender, nationality) and productivity (issue fixing time). Method: We consider issues solved from the GHTorrent dataset inferring gender and nationality of each team's members. We also evaluate the politeness of all comments involved in issue resolution. Results: Results show that higher gender diversity is linked with a lower team average issue fixing time (higher productivity), that nationality diversity is linked with lower team politeness and that gender diversity is linked with higher sentiment.},
author = {Marchesi, Marco OrtuGiuseppe DestefanisSteve CounsellStephen SwiftRoberto TonelliMichele},
doi = {10.1186/s40411-017-0044-y},
journal = {Journal of Software Engineering Research and Development},
number = {1},
title = {{How diverse is your team? Investigating gender and nationality diversity in GitHub teams}},
url = {http://link.springer.com/article/10.1186/s40411-017-0044-y},
volume = {5},
year = {2017}
}
@article{10.1007/s10664-019-09750-5,
author = {Zaidman, Carmine VassalloSebastiano PanichellaFabio PalombaSebastian ProkschHarald C GallAndy},
doi = {10.1007/s10664-019-09750-5},
journal = {Empirical Software Engineering},
number = {2},
title = {{How developers engage with static analysis tools in different contexts}},
url = {http://link.springer.com/article/10.1007/s10664-019-09750-5},
volume = {25},
year = {2020}
}
@inproceedings{Zampetti2017,
abstract = {Online resources of formal and informal documentation-such as reference manuals, forum discussions and tutorials-have become an asset to software developers, as they allow them to tackle problems and to learn about new tools, libraries, and technologies. This study investigates to what extent and for which purpose developers refer to external online resources when they contribute changes to a repository by raising a pull request. Our study involved (i) a quantitative analysis of over 150k URLs occurring in pull requests posted in GitHub, (ii) a manual coding of the kinds of software evolution activities performed in commits related to a statistically significant sample of 2,130 pull requests referencing external documentation resources, (iii) a survey with 69 participants, who provided feedback on how they use online resources and how they refer to them when filing a pull request. Results of the study indicate that, on the one hand, developers find external resources useful to learn something new or to solve specific problems, and they perceive useful referring such resources to better document changes. On the other hand, both interviews and repository mining suggest that external resources are still rarely referred in document changes.},
author = {Zampetti, F and Ponzanelli, L and Bavota, G and Mocci, A and Penta, M Di and Lanza, M},
booktitle = {2017 IEEE/ACM 25th International Conference on Program Comprehension (ICPC)},
doi = {10.1109/ICPC.2017.30},
isbn = { VO -},
keywords = {Context,Documentation,Documenting Changes,Empirical Study,Encoding,GitHub,Manuals,Online Resources,Software,Tutorials,Uniform resource locators,document handling,formal documentation,informal documentation,pull requests documentation,quantitative analysis,software developers,software evolution activity},
pages = {23--33},
title = {{How Developers Document Pull Requests with External References}},
year = {2017}
}
@article{10.1007/s10664-019-09781-y,
author = {Gonzalez-Barahona, Gema Rodr{\'{i}}guez-P{\'{e}}rezGregorio RoblesAlexander SerebrenikAndy ZaidmanDaniel M Germ{\'{a}}nJesus M},
doi = {10.1007/s10664-019-09781-y},
journal = {Empirical Software Engineering},
number = {2},
title = {{How bugs are born: a model to identify how bugs are introduced in software components}},
url = {http://link.springer.com/article/10.1007/s10664-019-09781-y},
volume = {25},
year = {2020}
}
@article{arXiv:1708.06860,
abstract = {Abstract: Increasingly, software developers are using a wide array of social collaborative platforms for software development and learning. In this work, we examined the similarities in developer's interests within and across GitHub and Stack Overflow. Our study finds that developers share common interests in GitHub and Stack Overflow, on average, 39{\%} of the GitHub repositories and Stack Overflow questions that a developer had participated fall in the common interests. Also, developers do share similar interests with other developers who co-participated activities in the two platforms. In particular, developers who co-commit and co-pull-request same GitHub repositories and co-answer same Stack Overflow questions, share more common interests compare to other developers who co-participate in other platform activities. △ Less},
author = {{Authors: Roy Ka-Wei Lee}, David Lo},
journal = {arXiv preprint arXiv:1708.06860},
title = {{GitHub and Stack Overflow: Analyzing Developer Interests Across Multiple Social Collaborative Platforms}},
year = {2017}
}
@inproceedings{7360574,
abstract = {This paper presents GitBull tool as a source code hosting Web application tailored for the university ecosystem. GitBull introduces the ideology of open source software development. The main aim of GitBull is to fill the gap between how students work on software development projects in university and how software is being developed in the work environment. GitBull helps students use source code versioning and collaboration tools, and reduce their learning curve when they enter the work environment. Students using GitBull and learning the Git source code versioning tool should be more prepared for the professional work environment. The application complements the Git source code versioning tool, by adding a visual user interface to some aspects while introducing some collaboration enhancement tools like the Issue Tracker and the Pull Request feature.},
author = {Qusef, A and Albadarneh, I and Albadarneh, A},
booktitle = {2015 IEEE Jordan Conference on Applied Electrical Engineering and Computing Technologies (AEECT)},
doi = {10.1109/AEECT.2015.7360574},
keywords = {computer aided instruction;computer science education;educational institutions;graphical user interfaces;professional aspects;public domain software;source code (software);GitBull tool;Web application;university ecosystem;open source software development projects;collaboration tools;learning curve reduction;work environment;Git source code versioning tool;professional work environment;visual user interface;collaboration enhancement tools;Issue Tracker;Pull Request feature;Collaboration;Servers;Computers;Companies;History;Open source software;Source Code Hosting;Source Code Management;Issue Tracker;Pull request},
pages = {1--6},
title = {{GitBull: Source code hosting web application}},
year = {2015}
}
@article{saito2016git,
abstract = {DSpace/Manakin Repository git-sprite:Supporting Tool for Pull-Based Software Development Model JavaScript is disabled for your browser. Some features of this site may not work without it. git-sprite:Supporting Tool for Pull-Based Software Development Model. Saito, Yusuke},
author = {Saito, Yusuke},
publisher = {奈良先端科学技術大学院大学},
title = {{git-sprite: Supporting Tool for Pull-Based Software Development Model}},
url = {https://library.naist.jp/dspace/handle/10061/10536},
year = {2016}
}
@article{10.1140/epjds/s13688-019-0202-z,
author = {Vasarhelyi, Balazs VedresOrsolya},
doi = {10.1140/epjds/s13688-019-0202-z},
journal = {EPJ Data Science},
number = {1},
title = {{Gendered behavior as a disadvantage in open source software development}},
url = {http://link.springer.com/article/10.1140/epjds/s13688-019-0202-z},
volume = {8},
year = {2019}
}
@article{DBLP:journals/peerj-cs/TerrellKMRMPS17,
author = {Terrell, Josh and Kofink, Andrew and Middleton, Justin and Rainear, Clarissa and Murphy-Hill, Emerson R and Parnin, Chris and Stallings, Jon},
doi = {10.7717/peerj-cs.111},
journal = {PeerJ Comput. Sci.},
pages = {e111},
title = {{Gender differences and bias in open source: pull request acceptance of women versus men}},
url = {https://doi.org/10.7717/peerj-cs.111},
volume = {3},
year = {2017}
}
@article{DBLP:journals/peerjpre/TerrellKMRMP16,
author = {Terrell, Josh and Kofink, Andrew and Middleton, Justin and Rainear, Clarissa and Murphy-Hill, Emerson R and Parnin, Chris},
doi = {10.7287/peerj.preprints.1733v1},
journal = {PeerJ Prepr.},
pages = {e1733},
title = {{Gender bias in open source: Pull request acceptance of women versus men}},
url = {https://doi.org/10.7287/peerj.preprints.1733v1},
volume = {4},
year = {2016}
}
@article{10.1007/s10664-015-9406-4,
abstract = {Complex software development projects rely on the contribution of teams of developers, who are required to collaborate and coordinate their efforts. The productivity of such development teams, i.e., how their size is related to the produced output, is an important consideration for project and schedule management as well as for cost estimation. The majority of studies in empirical software engineering suggest that - due to coordination overhead - teams of collaborating developers become less productive as they grow in size. This phenomenon is commonly paraphrased as Brooks' law of software project management, which states that “adding manpower to a software project makes it later”. Outside software engineering, the non-additive scaling of productivity in teams is often referred to as the Ringelmann effect, which is studied extensively in social psychology and organizational theory. Conversely, a recent study suggested that in Open Source Software (OSS) projects, the productivity of developers increases as the team grows in size. Attributing it to collective synergetic effects, this surprising finding was linked to the Aristotelian quote that “the whole is more than the sum of its parts”. Using a data set of 58 OSS projects with more than 580,000 commits contributed by more than 30,000 developers, in this article we provide a large-scale analysis of the relation between size and productivity of software development teams. Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect. Using fine-grained data on the association between developers and source code files, we investigate possible explanations for the observed relations between team size and productivity. In particular, we take a network perspective on developer-code associations in software development teams and show that the magnitude of the decrease in productivity is likely to be related to the growth dynamics of co-editing networks which can be interpreted as a first-order approximation of coordination requirements.},
author = {Schweitzer, Ingo ScholtesPavlin MavrodievFrank},
doi = {10.1007/s10664-015-9406-4},
journal = {Empirical Software Engineering},
number = {2},
title = {{From Aristotle to Ringelmann: a large-scale analysis of team productivity and coordination in Open Source Software projects}},
url = {http://link.springer.com/article/10.1007/s10664-015-9406-4},
volume = {21},
year = {2016}
}
@inproceedings{10.1145/3183440.3195085,
abstract = {Fork-based development allows developers to start development from existing software repository by copying the code files. However, when the number of forks grows, contributions are not always visible to others, unless an explicit merge-back attempt is made. To solve this problem, we implemented Forks Insight (www.forks-insight.com) to help developers get an overview of forks on GitHub. The current release version focuses on simple analytics for the high level overview which is lightweight, scalable and practical. It has a user-friendly interactive web interface with features like searching and tagging.},
address = {New York, NY, USA},
author = {Ren, Luyao and Zhou, Shurui and K{\"{a}}stner, Christian},
booktitle = {Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings},
doi = {10.1145/3183440.3195085},
isbn = {9781450356633},
issn = {2574-1934},
keywords = {,Fork-based development,Forks Insight,GitHub,GitHub Forks,Industries,Internet,Open source software,Open-source,Overview of forks,Software engineering,Software maintenance,Tagging,User interfaces,code files,fork-based development,high level overview,open-source,overview of forks,public domain software,release version,software maintenance,software repository,user interfaces,user-friendly interactive web interface},
pages = {179--180},
publisher = {Association for Computing Machinery},
series = {ICSE '18},
title = {{Forks Insight: Providing an Overview of GitHub Forks}},
url = {https://doi.org/10.1145/3183440.3195085},
year = {2018}
}
@article{10.1007/s10664-016-9444-6,
abstract = {An Application Programming Interface (API) provides a set of functionalities to a developer with the aim of enabling reuse. APIs have been investigated from different angles such as popularity usage and evolution to get a better understanding of their various characteristics. For such studies, software repositories are mined for API usage examples. However, many of the mining algorithms used for such purposes do not take type information into account. Thus making the results unreliable. In this paper, we aim to rectify this by introducing fine-GRAPE, an approach that produces fine-grained API usage information by taking advantage of type information while mining API method invocations and annotation. By means of fine-GRAPE, we investigate API usages from Java projects hosted on GitHub. We select five of the most popular APIs across GitHub Java projects and collect historical API usage information by mining both the release history of these APIs and the code history of every project that uses them. We perform two case studies on the resulting dataset. The first measures the lag time of each client. The second investigates the percentage of used API features. In the first case we find that for APIs that release more frequently clients are far less likely to upgrade to a more recent version of the API as opposed to clients of APIs that release infrequently. The second case study shows us that for most APIs there is a small number of features that is actually used and most of these features relate to those that have been introduced early in the APIs lifecycle.},
author = {Bacchelli, Anand Ashok SawantAlberto},
doi = {10.1007/s10664-016-9444-6},
journal = {Empirical Software Engineering},
number = {3},
title = {{fine-GRAPE: fine-grained APi usage extractor – an approach and dataset to investigate API usage}},
url = {http://link.springer.com/article/10.1007/s10664-016-9444-6},
volume = {22},
year = {2017}
}
@inproceedings{10.1145/3301326.3301380,
abstract = {A pull request is an important method for code contributions in GitHub that will be submitted when the developers would like to merge their code changes from their local machine to the main repository on which all source code in the project are stored. Before merging the code changes into the main repository, the developers have to request for a permission. If their source code is allowed to merge, the pull request status is accepted. On the other hand, if their source code is not allowed to merge, the pull request status is rejected. The pull request status may be rejected due to several factors, such as code complexity, code quality, the number of changed files, etc. Fixing the rejected pull requests will take some extra effort and time which may affect the project cost and timeline. This paper aims at finding the impact factors that are associated with the rejection of pull requests on GitHub and also discovering the relationships among impact factors by using the association rules in data mining.},
address = {New York, NY, USA},
author = {Pooput, Panthip and Muenchaisri, Pornsiri},
booktitle = {Proceedings of the 2018 VII International Conference on Network, Communication and Computing},
doi = {10.1145/3301326.3301380},
isbn = {9781450365536},
keywords = { Ansible, Association rules, Data mining, GitHub,Pull Request},
pages = {70--76},
publisher = {Association for Computing Machinery},
series = {ICNCC 2018},
title = {{Finding Impact Factors for Rejection of Pull Requests on GitHub}},
url = {https://doi.org/10.1145/3301326.3301380},
year = {2018}
}
@inproceedings{10.1109/ICSE-Companion.2019.00074,
abstract = {A software system's design determines many of its properties. An understanding of design is needed to maintain system properties as changes to the system are made. When developers lose track of the overall design, the system may not conform to its intended properties. I hypothesize that it is possible to solve the problems of design evaporation and erosion by recovering design information from written developer discussions and by leveraging the recovered information to help developers make better decisions. As part of investigating this hypothesis, I have built an automated classifier that is able to locate design information in discussions, at the paragraph level, by learning from manual annotations of discussions extracted from open source pull requests. I next plan to extract and represent the design information from the identified paragraphs and to show the usefulness of the information by creating tools to help notify developers of design information relevant to a task at hand.},
author = {Viviani, Giovanni},
booktitle = {Proceedings of the 41st International Conference on Software Engineering: Companion Proceedings},
doi = {10.1109/ICSE-Companion.2019.00074},
keywords = { design discussions, latent design, prediction model,conversations},
pages = {182--183},
publisher = {IEEE Press},
series = {ICSE '19},
title = {{Finding and Using Design Information in Discussions}},
url = {https://doi.org/10.1109/ICSE-Companion.2019.00074},
year = {2019}
}
@article{10.1007/s10664-019-09690-0,
author = {Jiang, Boyuan ChenZhen Ming (Jack)},
doi = {10.1007/s10664-019-09690-0},
journal = {Empirical Software Engineering},
number = {4},
title = {{Extracting and studying the Logging-Code-Issue- Introducing changes in Java-based large-scale open source software systems}},
url = {http://link.springer.com/article/10.1007/s10664-019-09690-0},
volume = {24},
year = {2019}
}
@inproceedings{10.1145/2875913.2875914,
abstract = {Recently, many researches propose that social media tools can promote the collaboration among developers, which are beneficial to the software development. Nevertheless, there is little empirical evidence to confirm that using @-mention has indeed a beneficial impact on the issues in GitHub. In this paper, we analyze the data from GitHub and give some insights on how @-mention is used in the issues (general-issues and pull-requests). Our statistical results indicate that, @-mention attracts more participants and tends to be used in the difficult issues. @-mention favors the solving process of issues by enlarging the visibility of issues and facilitating the developers' collaboration. In addition to this global study, our study also build a @-network based on the @-mention database we extract. Through the @-network, we can mine the relationships and characteristics of developers in GitHub's issues.},
address = {New York, NY, USA},
author = {Zhang, Yang and Wang, Huaimin and Yin, Gang and Wang, Tao and Yu, Yue},
booktitle = {Proceedings of the 7th Asia-Pacific Symposium on Internetware},
doi = {10.1145/2875913.2875914},
isbn = {9781450336413},
keywords = { @-mention, Issues, Social media,GitHub},
pages = {83--92},
publisher = {Association for Computing Machinery},
series = {Internetware '15},
title = {{Exploring the Use of @-Mention to Assist Software Development in GitHub}},
url = {https://doi.org/10.1145/2875913.2875914},
year = {2015}
}
@article{10.1007/s42486-019-00013-2,
abstract = {Recently, major software development platforms have started to provide automatic reviewer recommendation (ARR) services for pull requests to improve collaborative coding review process. However, the user experience of ARR is under-investigated. In this paper, we use a two-stage mixed-methods approach to study how software developers perceive and work with the Facebook mention bot, one of the most popular ARR bots in GitHub. Specifically, in Stage I, we conduct archival analysis on projects employing mention bot and a user survey to investigate bot performance. A year later, in Stage II, we revisit these projects and conduct additional surveys and interviews with three user groups: project owners, contributors and reviewers. Results show that developers appreciate mention bot saving their efforts, but are bothered by its unstable setting and unbalanced workload allocation. We conclude with design considerations for improving ARR services.},
address = {New York, NY, USA},
author = {Peng, Zhenhui and Yoo, Jeehoon and Xia, Meng and Kim, Sunghun and Ma, Xiaojuan and Ma, Zhenhui PengXiaojuan},
doi = {10.1007/s42486-019-00013-2},
isbn = {9781450365086},
journal = {Proceedings of the Sixth International Symposium of Chinese CHI},
keywords = {,Automatic reviewer recommendation services,mixed-methods,software development platform,user experience},
number = {3},
pages = {152--155},
publisher = {Association for Computing Machinery},
series = {ChineseCHI '18},
title = {{Exploring how software developers work with mention bot in GitHub}},
url = {http://link.springer.com/article/10.1007/s42486-019-00013-2 https://doi.org/10.1145/3202667.3202694},
volume = {1},
year = {2019}
}
@inproceedings{8103456,
abstract = {Peer code reviews are important for giving and receiving peer feedback, but the code review process is time consuming. Static analysis tools can help reduce reviewer effort by catching common mistakes prior to peer code review. Ideally, contributors would use static analysis tools prior to pull request submission so common mistakes could be addressed first, before invoking the reviewer. To explore the potential efficiency gains for peer reviewers, we explore the overlap between reviewer comments on pull requests and warnings from the PMD static analysis tool. In an empirical study of 274 comments from 92 pull requests on GitHub, we observed that PMD overlapped with nearly 16{\%} of the reviewer comments, indicating a time benefit to the reviewer if static analyzers would have been used prior to pull request submission. Using the non-overlapping set of comments, we identify four additional rules that, if implemented, could further reduce reviewer effort.},
author = {Singh, D and Sekar, V R and Stolee, K T and Johnson, B},
booktitle = {2017 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC)},
doi = {10.1109/VLHCC.2017.8103456},
issn = {1943-6106},
keywords = {program diagnostics;public domain software;static analysis tools;code review effort;peer code reviews;code review process;peer reviewers;reviewer comments;PMD static analysis tool;static analyzers;pull requests;GitHub;Tools;Standards;Encoding;Java;Visualization;Manuals},
pages = {101--105},
title = {{Evaluating how static analysis tools can reduce code review effort}},
year = {2017}
}
@article{arXiv:1709.03777,
abstract = {Abstract: Trust is a factor that dramatically contributes to the success or failure of distributed software teams. We present a research model showing that social communication between distant developers enables the affective appraisal of trustworthiness even from a distance, thus increasing project performance. To overcome the limitations of self-reported data, typically questionnaires, we focus on software projects following a pull request-based development model and approximate the overall performance of a software project with the history of successful collaborations occurring between developers. △ Less},
author = {{Authors: Fabio Calefato}, Filippo Lanubile},
doi = {10.1002/itl2.6},
journal = {arXiv preprint arXiv:1709.03777},
title = {{Establishing Personal Trust-based Connections in Distributed Teams}},
year = {2017}
}
@article{10.1007/s42979-020-00175-2,
author = {Rashid, Muhammad IlyasSiffat Ullah KhanNasir},
doi = {10.1007/s42979-020-00175-2},
journal = {SN Computer Science},
number = {3},
title = {{Empirical Validation of Software Integration Practices in Global Software Development}},
url = {http://link.springer.com/article/10.1007/s42979-020-00175-2},
volume = {1},
year = {2020}
}
@article{arXiv:2003.11772,
abstract = {Abstract: Continuous Integration (CI) is a development practice where developers frequently integrate code into a common codebase. After the code is integrated, the CI server runs a test suite and other tools to produce a set of reports (e.g., output of linters and tests). If the result of a CI test run is unexpected, developers have the option to manually restart the build, re-running the same test suite on the same code; this can reveal build flakiness, if the restarted build outcome differs from the original build. In this study, we analyze restarted builds, flaky builds, and their impact on the development workflow. We observe that developers restart at least 1.72{\%} of builds, amounting to 56,522 restarted builds in our Travis CI dataset. We observe that more mature and more complex projects are more likely to include restarted builds. The restarted builds are mostly builds that are initially failing due to a test, network problem, or a Travis CI limitations such as execution timeout. Finally, we observe that restarted builds have a major impact on development workflow. Indeed, in 54.42{\%} of the restarted builds, the developers analyze and restart a build within an hour of the initial failure. This suggests that developers wait for CI results, interrupting their workflow to address the issue. Restarted builds also slow down the merging of pull requests by a factor of three, bringing median merging time from 16h to 48h. △ Less},
author = {{Authors: Thomas Durieux Claire Le Goues}, Michael Hilton Rui Abreu},
doi = {10.1145/3379597.3387460},
journal = {arXiv preprint arXiv:2003.11772},
title = {{Empirical Study of Restarted and Flaky Builds on Travis CI}},
year = {2020}
}
@inproceedings{10.1109/SEmotion.2019.00017,
abstract = {Pull-request based workflows are popular trends of modern software development platform such as GitHub. A pull-request notifies other developers that new changes are proposed, a code review process follows the pull-request that may be merged in the main branch if other developers accept the changes. Many factors influence the acceptance of pull-requests. Since open source software is based on collaboration, it is essential to discover how the affect expressed by developer discussing pull-request issues, namely how they collaborate, influences the acceptance of the pull-request proposed. In this study we analysed the relations with the affect expressed in pull-request issues' comments and whether an issue is merged in the main branch or not. We focused on pull-request issues and we found that issues with higher level anger, sadness, arousal and valence are less likely to be merged while issues with higher level of valence, joy are more likely to be merged. Positive affect indicates a good collaboration environment, and our finding shows that this healthy collaboration is likely to increase the acceptance of pull-requests.},
author = {Ortu, Marco and Marchesi, Michele and Tonelli, Roberto},
booktitle = {Proceedings of the 4th International Workshop on Emotion Awareness in Software Engineering},
doi = {10.1109/SEmotion.2019.00017},
keywords = { human aspect,software engineering},
pages = {46--48},
publisher = {IEEE Press},
series = {SEmotion '19},
title = {{Empirical Analysis of Affect of Merged Issues on GitHub}},
url = {https://doi.org/10.1109/SEmotion.2019.00017},
year = {2019}
}
@article{Iyer2019,
abstract = {In this paper, we examine the influence of personality traits of developers on the pull request evaluation process in GitHub. We first replicate Tsay et al.'s work that examined the influence of social factors (e.g., ‘social distance') and technical factors (e.g., test file inclusion) for evaluating contributions, and then extend it with personality-based factors. In particular, we extract the Big Five personality traits (Openness, Conscientiousness, Extraversion, Agreeableness, and Neuroticism) of developers from their online digital footprints, such as pull request comments. We analyze the personality traits of 16,935 active developers from 1,860 projects and compare their relative importance to other non-personality factors from past research, in the pull request evaluation process. We find that pull requests from authors (requesters) who are more open and conscientious, but less extroverted, have a higher chance of approval. Furthermore, pull requests that are closed by developers (closers) who are more conscientious, extroverted, and neurotic, have a higher likelihood of acceptance. The larger the difference in personality traits between the requester and the closer, the more positive effect it has on pull request acceptance. Finally, although the effect of personality traits is significant and comparable to technical factors, we find that social factors are still more influential on the likelihood of pull request acceptance.},
author = {Iyer, R N and Yun, S A and Nagappan, M and Hoey, J},
doi = {10.1109/TSE.2019.2960357},
issn = {1939-3520 VO -},
journal = {IEEE Transactions on Software Engineering},
keywords = {Big Five,Dictionaries,GitHub,Psychology,Robots,Social factors,Software,Software engineering,Task analysis,five-factor model,online collaborative environments,open source systems,personality,pull request},
pages = {1},
title = {{Effects of Personality Traits on Pull Request Acceptance}},
year = {2019}
}
@mastersthesis{iyer2019effects,
abstract = {Social interactions in the form of discussion are an indispensable part of collaborative software development. The discussions are essential for developers to share their views and to form a strong relationship with other teammates. These discussions invoke both positive},
author = {Iyer, Rahul},
school = {University of Waterloo},
title = {{Effects of Personality Traits and Emotional Factors in Pull Request Acceptance.}},
url = {https://uwspace.uwaterloo.ca/handle/10012/14952},
year = {2019}
}
@article{10.1007/s10664-019-09714-9,
author = {Hansson, Md Abdullah Al MamunChristian BergerJ{\"{o}}rgen},
doi = {10.1007/s10664-019-09714-9},
journal = {Empirical Software Engineering},
number = {4},
title = {{Effects of measurements on correlations of software code metrics}},
url = {http://link.springer.com/article/10.1007/s10664-019-09714-9},
volume = {24},
year = {2019}
}
@inproceedings{10.1145/2950290.2950364,
abstract = { Code contributions in Free/Libre and Open Source Software projects are controlled to maintain high-quality of software. Alternatives to patch-based code contribution tools such as mailing lists and issue trackers have been developed with the pull request systems being the most visible and widely available on GitHub. Is the code contribution process more effective with pull request systems? To answer that, we quantify the effectiveness via the rates contributions are accepted and ignored, via the time until the first response and final resolution and via the numbers of contributions. To control for the latent variables, our study includes a project that migrated from an issue tracker to the GitHub pull request system and a comparison between projects using mailing lists and pull request systems. Our results show pull request systems to be associated with reduced review times and larger numbers of contributions. However, not all the comparisons indicate substantially better accept or ignore rates in pull request systems. These variations may be most simply explained by the differences in contribution practices the projects employ and may be less affected by the type of tool. Our results clarify the importance of understanding the role of tools in effective management of the broad network of potential contributors and may lead to strategies and practices making the code contribution more satisfying and efficient from both contributors' and maintainers' perspectives. },
address = {New York, NY, USA},
author = {Zhu, Jiaxin and Zhou, Minghui and Mockus, Audris},
booktitle = {Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering},
doi = {10.1145/2950290.2950364},
isbn = {9781450342186},
keywords = { Code contribution, FLOSS, issue tracker, mailing list, pull request,effectiveness},
pages = {871--882},
publisher = {Association for Computing Machinery},
series = {FSE 2016},
title = {{Effectiveness of Code Contribution: From Patch-Based to Pull-Request-Based Tools}},
url = {https://doi.org/10.1145/2950290.2950364},
year = {2016}
}
@article{DBLP:journals/corr/abs-2007-04816,
abstract = {Abstract: Pull request (PR) based development, which is a norm for the social coding platforms, entails the challenge of evaluating the contributions of, often unfamiliar, developers from across the open source ecosystem and, conversely, submitting a contribution to a project with unfamiliar maintainers. Previous studies suggest that the decision of accepting or rejecting a PR may be influenced by a diverging set of technical and social factors, but often focus on relatively few projects, do not consider ecosystem-wide measures, or the possible non-monotonic relationships between the predictors and PR acceptance probability. We aim to shed light on this important decision making process by testing which measures significantly affect the probability of PR acceptance on a significant fraction of a large ecosystem, rank them by their relative importance in predicting PR acceptance, and determine the shape of the functions that map each predictor to PR acceptance. We proposed seven hypotheses regarding which technical and social factors might affect PR acceptance and created 17 measures based on them. Our dataset consisted of 470,925 PRs from 3349 popular NPM packages and 79,128 GitHub users who created those. We tested which of the measures affect PR acceptance and ranked the significant measures by their importance in a predictive model. Our predictive model had and AUC of 0.94, and 15 of the 17 measures were found to matter, including five novel ecosystem-wide measures. Measures describing the number of PRs submitted to a repository and what fraction of those get accepted, and signals about the PR review phase were most significant. We also discovered that only four predictors have a linear influence on the PR acceptance probability while others showed a more complicated response. △ Less},
archivePrefix = {arXiv},
arxivId = {2007.04816},
author = {Dey, Tapajit and Mockus, Audris and {Authors: Tapajit Dey}, Audris Mockus},
doi = {10.1145/3382494.3410685},
eprint = {2007.04816},
journal = {arXiv preprint arXiv:2007.04816},
title = {{Effect of Technical and Social Factors on Pull Request Quality for the {\{}NPM{\}} Ecosystem}},
url = {https://arxiv.org/abs/2007.04816},
volume = {abs/2007.04816},
year = {2020}
}
@article{10.1007/s10664-018-9602-0,
author = {Li, Yuanrui FanXin XiaDavid LoShanping},
doi = {10.1007/s10664-018-9602-0},
journal = {Empirical Software Engineering},
number = {6},
title = {{Early prediction of merged code changes to prioritize reviewing tasks}},
url = {http://link.springer.com/article/10.1007/s10664-018-9602-0},
volume = {23},
year = {2018}
}
@inproceedings{Ying2016,
abstract = {Pull-Request (PR) is a primary way of code contribution from developers to improve quality of software projects in GitHub. For a popular GitHub project, tens of PR are submitted daily, while only a small number of developers, i.e core developers, have the grant to judge whether to merge these changes into the main branches or not. Due to the time-consumption of PR review and the diversity of PR aspects, it is becoming a big challenge for core developers to quickly discover the useful PR. Currently, recommending appropriate reviewers (developers) for incoming PR to quickly collect meaningful comments, is treated as an effective and crowdsourced way to help core developers to make decisions and thus accelerate project development. In this paper, we propose a reviewer recommendation approach (EARec) which simultaneously considers developer expertise and authority. Specifically, we first construct a graph of incoming PR and possible reviewers, and then take advantage of text similarity of PR and social relations of reviewers to find the appropriate reviewers. The experimental analysis on MSR Mining Challenge Dataset$\backslash$footnote{\{}http://ghtorrent.org/msr14.html{\}} provides good evaluation for our approach in terms of precision and recall.},
author = {Ying, H and Chen, L and Liang, T and Wu, J},
booktitle = {2016 IEEE/ACM 3rd International Workshop on CrowdSourcing in Software Engineering (CSI-SE)},
doi = {10.1109/CSI-SE.2016.013},
isbn = { VO -},
keywords = {Acceleration,Collaboration,Control systems,Data mining,EARec,GitHub project,Large scale integration,MSR mining challenge dataset$\backslash$footnote,PR aspects,PR graph,PR review,Semantics,Software,code contribution,core developers,crowdsourcing,project development,pull-request reviewer recommendation,recommender systems,software engineering,software project quality},
pages = {29--35},
title = {{EARec: Leveraging Expertise and Authority for Pull-Request Reviewer Recommendation in GitHub}},
year = {2016}
}
@inproceedings{10.1145/3361242.3361254,
abstract = {In open source communities (e.g., GitHub), developers frequently submit pull requests to fix bugs or add new features during development process. Since the process of pull request is uncoordinated and distributed, it causes massive duplication. Usually, only the first pull request qualified by reviewers can be merged to the main branch of the repository, and the others are regarded as duplication by maintainers. Since the duplication largely aggravates workloads of project reviewers and maintainers, the evolutionary process of open source repositories is delayed. To identify the duplicate pull requests automatically, Ren et al. proposed a state-of-the-art approach that models a pull request by nine features and determine whether a given request is duplicate with the other existing requests or not. Nevertheless, we notice that their approach overlooked the time factor which is a significant feature for the task. In this study, we investigate the influence of time factor and improve the pull request representation. We assume that two pull requests are more likely duplicate when their created time are close to each other. We verify the assumption based on 26 open source repositories from GitHub with over 100,000 pairs of pull requests. We integrate the time feature to the nine features proposed by Ren et al. and the experimental results show that it can substantially improve the performance of Ren et al.'s work by 14.36{\%} and 11.93{\%} in terms of F1-score@1 and F1-score@5, respectively.},
address = {New York, NY, USA},
author = {Wang, Qingye and Xu, Bowen and Xia, Xin and Wang, Ting and Li, Shanping},
booktitle = {Proceedings of the 11th Asia-Pacific Symposium on Internetware},
doi = {10.1145/3361242.3361254},
isbn = {9781450377010},
keywords = { GitHub, Time Factor,Duplicate Pull Request},
publisher = {Association for Computing Machinery},
series = {Internetware '19},
title = {{Duplicate Pull Request Detection: When Time Matters}},
url = {https://doi.org/10.1145/3361242.3361254},
year = {2019}
}
@article{arXiv:1604.01450,
abstract = {Technical Debt is a term used to classify non-optimal solutions during software development. These solutions cause several maintenance problems and hence they should be avoided or at least documented. Although there are a considered number of studies that focus on the identification of Technical Debt, we focus on the identification of Technical Debt in pull requests. Specifically, we conduct an investigation to reveal the different types of Technical Debt that can lead to the rejection of pull requests. From the analysis of 1,722 pull requests, we classify Technical Debt in seven categories namely design, documentation, test, build, project convention, performance, or security debt. Our results indicate that the most common category of Technical Debt is design with 39.34{\%}, followed by test with 23.70{\%} and project convention with 15.64{\%}. We also note that the type of Technical Debt influences on the size of push request discussions, e.g., security and project convention debts instigate more discussion than the other types.},
address = {Porto Alegre, BRA},
author = {Silva, Marcelino C O and Valente, Marco Tulio and Terra, Ricardo and {Authors: Marcelino Campos Oliveira Silva Marco Tulio Valente}, Ricardo Terra},
isbn = {9788576693178},
journal = {arXiv preprint arXiv:1604.01450},
keywords = {,GitHub,Pull Request,Technical Debt},
pages = {248--254},
publisher = {Brazilian Computer Society},
series = {SBSI 2016},
title = {{Does Technical Debt Lead to the Rejection of Pull Requests?}},
year = {2016}
}
@article{arXiv:1908.09321,
abstract = {Abstract: Background. Pull requests are a common practice for contributing and reviewing contributions, and are employed both in open-source and industrial contexts. One of the main goals of code reviews is to find defects in the code, allowing project maintainers to easily integrate external contributions into a project and discuss the code contributions. Objective. The goal of this paper is to understand whether code quality is actually considered when pull requests are accepted. Specifically, we aim at understanding whether code quality issues such as code smells, antipatterns, and coding style violations in the pull request code affect the chance of its acceptance when reviewed by a maintainer of the project. Method. We conducted a case study among 28 Java open-source projects, analyzing the presence of 4.7 M code quality issues in 36 K pull requests. We analyzed further correlations by applying Logistic Regression and seven machine learning techniques (Decision Tree, Random Forest, Extremely Randomized Trees, AdaBoost, Gradient Boosting, XGBoost). Results. Unexpectedly, code quality turned out not to affect the acceptance of a pull request at all. As suggested by other works, other factors such as the reputation of the maintainer and the importance of the feature delivered might be more important than code quality in terms of pull request acceptance. Conclusions. Researchers already investigated the influence of the developers' reputation and the pull request acceptance. This is the first work investigating if quality of the code in pull requests affects the acceptance of the pull request or not. We recommend that researchers further investigate this topic to understand if different measures or different tools could provide some useful measures. △ Less},
archivePrefix = {arXiv},
arxivId = {1908.09321},
author = {{Authors: Valentina Lenarduzzi Vili Nikkola}, Nyyti Saarim{\"{a}}ki Davide Taibi and Lenarduzzi, Valentina and Nikkola, Vili and Saarim{\"{a}}ki, Nyyti and Taibi, Davide},
eprint = {1908.09321},
journal = {arXiv preprint arXiv:1908.09321},
title = {{Does Code Quality Affect Pull Request Acceptance? An empirical study}},
url = {http://arxiv.org/abs/1908.09321},
volume = {abs/1908.09321},
year = {2019}
}
@article{7164225,
abstract = {Developers have contributed to open-source projects by forking the code and submitting pull requests. Once a pull request is submitted, interested parties can review the set of changes, discuss potential modifications, and even push additional commits if necessary. Mining artifacts that were committed together during history of pull-requests makes it possible to infer change couplings among these artifacts. Supported by the Conway's Law, whom states that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”, we hypothesize that social network analysis (SNA) is able to identify strong and weak change dependencies. In this paper, we used statistical models relying on centrality, ego, and structural holes metrics computed from communication networks to predict co-changes among files included in pull requests submitted to the Ruby on Rails project. To the best of our knowledge, this is the first study to employ SNA metrics to predict change dependencies from Github projects.},
author = {Wiese, I S and Kuroda, R T and R{\'{e}}, R and Bulh{\'{o}}es, R S and Oliva, G A and Gerosa, M A},
doi = {10.1109/TLA.2015.7164225},
issn = {1548-0992},
journal = {IEEE Latin America Transactions},
keywords = {public domain software;software metrics;historical metrics;developer communication;change coupling prediction;open-source projects;pull requests;Conway law;social network analysis;SNA metrics;change dependencies;statistical models;structural hole metrics;communication networks;Ruby on Rails project;Github projects;Measurement;Receivers;change coupling;communication network;Conway's law;social network analysis;structural holes metrics},
number = {6},
pages = {1979--1988},
title = {{Do historical metrics and developers communication aid to predict change couplings?}},
volume = {13},
year = {2015}
}
@inproceedings{10.1145/2597073.2597115,
abstract = { Design is often raised in the literature as important to attaining various properties and characteristics in a software system. At least for open-source projects, it can be hard to find evidence of ongoing design work in the technical artifacts produced as part of the development. Although developers usually do not produce specific design documents, they do communicate about design in different ways. In this paper, we provide quantitative evidence that developers address design through discussions in commits, issues, and pull requests. To achieve this, we built a discussions' classifier and automatically labeled 102,122 discussions from 77 projects. Based on this data, we make four observations about the projects: i) on average, 25{\%} of the discussions in a project are about design; ii) on average, 26{\%} of developers contribute to at least one design discussion; iii) only 1{\%} of the developers contribute to more than 15{\%} of the discussions in a project; and iv) these few developers who contribute to a broad range of design discussions are also the top committers in a project. },
address = {New York, NY, USA},
author = {Brunet, Jo{\~{a}}o and Murphy, Gail C and Terra, Ricardo and Figueiredo, Jorge and Serey, Dalton},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
doi = {10.1145/2597073.2597115},
isbn = {9781450328630},
keywords = { Design Discussions, Machine Learning,Empirical Study},
pages = {340--343},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{Do Developers Discuss Design?}},
url = {https://doi.org/10.1145/2597073.2597115},
year = {2014}
}
@article{10.1007/s10664-020-09837-4,
author = {Mockus, Andrey KrutauzTapajit DeyPeter C RigbyAudris},
doi = {10.1007/s10664-020-09837-4},
journal = {Empirical Software Engineering},
title = {{Do code review measures explain the incidence of post-release defects?}},
url = {http://link.springer.com/article/10.1007/s10664-020-09837-4},
year = {2020}
}
@inproceedings{10.1145/2889160.2891035,
abstract = {Visible demographic characteristics are seen as elements of bias in offline work environments. In this study, we investigate the influence of the geographical location on the evaluation of pull requests in GitHub -- the most popular online collaborative code development environment. We use a mixed-methods approach and present analyses of 70,000+ pull requests and 2,500+ survey responses. Quantitative analysis of GitHub projects' data suggests that the geographical location significantly explains the pull request acceptance decisions. These observations are in agreement with the perceptions of submitters based on their experiences with bias. Integrators feel that it is easy to work with contributors from the same geographical location and that they encourage contributors from the same geographical location. However, integrators do not feel that contributors from some countries are better at writing pull requests compared to others.},
address = {New York, NY, USA},
author = {Rastogi, Ayushi},
booktitle = {Proceedings of the 38th International Conference on Software Engineering Companion},
doi = {10.1145/2889160.2891035},
isbn = {9781450342056},
keywords = { empirical studies, software process,empirical software engineering},
pages = {665--667},
publisher = {Association for Computing Machinery},
series = {ICSE '16},
title = {{Do Biases Related to Geographical Location Influence Work-Related Decisions in GitHub?}},
url = {https://doi.org/10.1145/2889160.2891035},
year = {2016}
}
@article{arXiv:1908.02320,
abstract = {Abstract: Developer contribution guidelines are used in social coding sites like GitHub to explain and shape the process a project expects contributors to follow. They set standards for all participants and "save time and hassle caused by improperly created pull requests or issues that have to be rejected and resubmitted" (GitHub). Yet, we lack a systematic understanding of the content of a typical contribution guideline, as well as the extent to which these guidelines are followed in practice. Additionally, understanding how guidelines may impact projects that use Continuous Integration as part of the contribution process is of particular interest. To address this knowledge gap, we conducted a mixed-methods study of 53 GitHub projects with explicit contribution guidelines and coded the guidelines to extract key themes. We then created a process model using GitHub activity data (e.g., commit, new issue, new pull request) to compare the actual activity with the prescribed contribution guidelines. We show that approximately 68{\%} of these projects diverge significantly from the expected process. △ Less},
author = {{Authors: Omar Elazhary Margaret-Anne Storey}, Neil Ernst Andy Zaidman},
journal = {arXiv preprint arXiv:1908.02320},
title = {{Do as I Do, Not as I Say: Do Contribution Guidelines Match the GitHub Contribution Process?}},
year = {2019}
}
@inproceedings{10.1145/2695664.2695884,
abstract = {A new collaboration approach is becoming increasingly common in open-source projects: the pull request model. In this kind of collaboration, developers that do not belong to the core team of a project can submit contributions to the core team. In projects that receive many pull requests, the task of assigning developers to analyze them is a difficult one. In this work, we propose to use data mining techniques, more specifically, classification strategies, in order to suggest the most appropriate developers to analyze a contribution, considering the pull request model. The experiments were conducted using 21 open source projects, each one characterized by 14 attributes. The first set of experiments aimed at indicating just one developer to analyze the pull request. The obtained predictive accuracy ranged from 22.45{\%} to 68.27{\%}. The Random Forest classifier achieved the best result in 76{\%} on the projects. In the second set of experiments, we conclude that, when suggesting three developers to analyze a pull request, the chance of identifying the developer that actually analyzed the pull request ranged from 47.33{\%} to 95.47{\%}.},
address = {New York, NY, USA},
author = {{de Lima J{\'{u}}nior}, Manoel Limeira and Soares, Daric{\'{e}}lio Moreira and Plastino, Alexandre and Murta, Leonardo},
booktitle = {Proceedings of the 30th Annual ACM Symposium on Applied Computing},
doi = {10.1145/2695664.2695884},
isbn = {9781450331968},
keywords = { distributed software development, pull request assignment,pull-based development},
pages = {1567--1572},
publisher = {Association for Computing Machinery},
series = {SAC '15},
title = {{Developers Assignment for Analyzing Pull Requests}},
url = {https://doi.org/10.1145/2695664.2695884},
year = {2015}
}
@inproceedings{10.1109/ASE.2019.00107,
abstract = {Evidence shows that developer reputation is extremely important when accepting pull requests or resolving reported issues. It is particularly salient in Free/Libre Open Source Software since the developers are distributed around the world, do not work for the same organization and, in most cases, never meet face to face. The existing solutions to expose developer reputation tend to be forge specific (GitHub), focus on activity instead of impact, do not leverage social or technical networks, and do not correct often misspelled developer identities. We aim to remedy this by amalgamating data from all public Git repositories, measuring the impact of developer work, expose developer's collaborators, and correct notoriously problematic developer identity data. We leverage World of Code (WoC), a collection of an almost complete (and continuously updated) set of Git repositories by first allowing developers to select which of the 34 million(M) Git commit author IDs belong to them and then generating their profiles by treating the selected collection of IDs as that single developer. As a side-effect, these selections serve as a training set for a supervised learning algorithm that merges multiple identity strings belonging to a single individual. As we evaluate the tool and the proposed impact measure, we expect to build on these findings to develop reputation badges that could be associated with pull requests and commits so developers could easier trust and prioritize them.},
author = {Amreen, Sadika and Karnauch, Andrey and Mockus, Audris},
booktitle = {Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering},
doi = {10.1109/ASE.2019.00107},
isbn = {9781728125084},
keywords = { identity disambiguation, software ecosystem,developer reputation},
pages = {1082--1085},
publisher = {IEEE Press},
series = {ASE '19},
title = {{Developer Reputation Estimator (DRE)}},
url = {https://doi.org/10.1109/ASE.2019.00107},
year = {2019}
}
@inproceedings{10.1145/3131704.3131725,
abstract = {The widespread use of pull-requests boosts the development and evolution for many open source software projects. However, due to the parallel and uncoordinated nature of development process in GitHub, duplicate pull-requests may be submitted by different contributors to solve the same problem. Duplicate pull-requests increase the maintenance cost of GitHub, result in the waste of time spent on the redundant effort of code review, and even frustrate developers' willing to offer continuous contribution. In this paper, we investigate using text information to automatically detect duplicate pull-requests in GitHub. For a new-arriving pull-request, we compare the textual similarity between it and other existing pull-requests, and then return a candidate list of the most similar ones. We evaluate our approach on three popular projects hosted in GitHub, namely Rails, Elasticsearch and Angular.JS. The evaluation shows that about 55.3{\%} -- 71.0{\%} of the duplicates can be found when we use the combination of title similarity and description similarity.},
address = {New York, NY, USA},
author = {Li, Zhixing and Yin, Gang and Yu, Yue and Wang, Tao and Wang, Huaimin},
booktitle = {Proceedings of the 9th Asia-Pacific Symposium on Internetware},
doi = {10.1145/3131704.3131725},
isbn = {9781450353137},
keywords = { Pull-request, code review, duplicate detection,textual similarity},
publisher = {Association for Computing Machinery},
series = {Internetware'17},
title = {{Detecting Duplicate Pull-Requests in GitHub}},
url = {https://doi.org/10.1145/3131704.3131725},
year = {2017}
}
@article{arXiv:2002.02056,
abstract = {Abstract: Project based learning (PBL) for software development (we call it software development PBL) has garnered attention as a practical educational method. A number of studies have reported on the introduction of social coding tools such as GitHub, in software development PBL. In education, it is important to give feedback (advice, error corrections, and so on) to learners, especially in software development PBL because almost all learners tackle practical software development from the viewpoint of technical and managerial aspects for the first time. This study regards inspection that is conducted in general software development activities as an opportunity to provide feedback and proposes the inspection process using the pull request on GitHub. By applying the proposed process to an actual software development PBL, we enable giving feedback to the accurate locations of artifacts the learners created. △ Less},
author = {{Authors: Yutsuki Miyashita Yuki Yamada}, Hiroaki Hashiura Atsuo Hazeyama},
journal = {arXiv preprint arXiv:2002.02056},
title = {{Design of the Inspection Process Using the GitHub Flow in Project Based Learning for Software Engineering and Its Practice}},
year = {2020}
}
@inproceedings{7503736,
abstract = {Micro-clones are small pieces of redundant code, such as repeated subexpressions or statements. In this paper, we establish the considerations and value toward automated detection and removal of micro-clones at scale. We leverage the Boa software mining infrastructure to detect micro-clones in a data set containing 380,125 Java repositories, and yield thousands of instances where redundant code may be safely removed. By filtering our results to target popular Java projects on GitHub, we proceed to issue 43 pull requests that patch micro-clones. In summary, 95{\%} of our patches to active GitHub repositories are merged rapidly (within 15 hours on average). Moreover, none of our patches were contested; they either constituted a real flaw, or have not been considered due to repository inactivity. Our results suggest that the detection and removal of micro-clones is valued by developers, can be automated at scale, and may be fixed with rapid turnaround times.},
author = {van Tonder, R and {Le Goues}, C},
booktitle = {2016 IEEE 24th International Conference on Program Comprehension (ICPC)},
doi = {10.1109/ICPC.2016.7503736},
keywords = {data mining;Java;redundancy;security of data;software maintenance;source code (software);redundant code;automated microclone removal;automated microclone detection;Boa software mining infrastructure;Java repositories;data set;GitHub repositories;repository inactivity;rapid turnaround times;Cloning;Java;Software;Data mining;DSL;Security;History},
pages = {1--4},
title = {{Defending against the attack of the micro-clones}},
year = {2016}
}
@article{10.1007/s11771-020-4308-z,
author = {张莉, Jing Jiang 蒋竞Jia-teng Zheng 郑嘉腾Yun Yang 杨云Li Zhang},
doi = {10.1007/s11771-020-4308-z},
journal = {Journal of Central South University},
number = {2},
title = {{CTCPPre: A prediction method for accepted pull requests in GitHub}},
url = {http://link.springer.com/article/10.1007/s11771-020-4308-z},
volume = {27},
year = {2020}
}
@inproceedings{DBLP:conf/seke/ZhangJM20,
author = {Zhang, Li and Jiang, Jing and Mohamed, Abdillah},
booktitle = {The 32nd International Conference on Software Engineering and Knowledge Engineering, {\{}SEKE{\}} 2020, {\{}KSIR{\}} Virtual Conference Center, USA, July 9-19, 2020},
doi = {10.18293/SEKE2020-072},
editor = {Garc$\backslash$'$\backslash$ia-Castro, Ra{\'{u}}l},
pages = {435--438},
publisher = {{\{}KSI{\}} Research Inc.},
title = {{Cross-project Reopened Pull Request Prediction in GitHub {\{}(S){\}}}},
url = {https://doi.org/10.18293/SEKE2020-072},
year = {2020}
}
@article{10.1007/s11704-017-6573-z,
author = {Wang, Zhixing LiGang YinTao WangYang ZhangYue YuHuaimin},
doi = {10.1007/s11704-017-6573-z},
journal = {Frontiers of Computer Science},
number = {5},
title = {{Correlation-based software search by leveraging software term database}},
url = {http://link.springer.com/article/10.1007/s11704-017-6573-z},
volume = {12},
year = {2018}
}
@inproceedings{10.1145/2889160.2889244,
abstract = {Peer code review locates common coding rule violations and simple logical errors in the early phases of software development, and thus reduces overall cost. However, in GitHub, identifying an appropriate code reviewer for a pull request is a non-trivial task given that reliable information for reviewer identification is often not readily available. In this paper, we propose a code reviewer recommendation technique that considers not only the relevant cross-project work history (e.g., external library experience) but also the experience of a developer in certain specialized technologies associated with a pull request for determining her expertise as a potential code reviewer. We first motivate our technique using an exploratory study with 10 commercial projects and 10 associated libraries external to those projects. Experiments using 17,115 pull requests from 10 commercial projects and six open source projects show that our technique provides 85{\%}-- 92{\%} recommendation accuracy, about 86{\%} precision and 79{\%}--81{\%} recall in code reviewer recommendation, which are highly promising. Comparison with the state-of-the-art technique also validates the empirical findings and the superiority of our recommendation technique.},
address = {New York, NY, USA},
author = {Rahman, Mohammad Masudur and Roy, Chanchal K and Collins, Jason A},
booktitle = {Proceedings of the 38th International Conference on Software Engineering Companion},
doi = {10.1145/2889160.2889244},
isbn = {9781450342056},
keywords = { GitHub, code reviewer recommendation, cross-project experience, specialized technology experience,pull request},
pages = {222--231},
publisher = {Association for Computing Machinery},
series = {ICSE '16},
title = {{CoRReCT: Code Reviewer Recommendation in GitHub Based on Cross-Project and Technology Experience}},
url = {https://doi.org/10.1145/2889160.2889244},
year = {2016}
}
@article{arXiv:1807.04130,
abstract = { Peer code review locates common coding standard violations and simple logical errors in the early phases of software development, and thus, reduces overall cost. Unfortunately, at GitHub, identifying an appropriate code reviewer for a pull request is challenging given that reliable information for reviewer identification is often not readily available. In this paper, we propose a code reviewer recommendation tool-CORRECT-that considers not only the relevant cross-project work experience (e.g., external library experience) of a developer but also her experience in certain specialized technologies (e.g., Google App Engine) associated with a pull request for determining her expertise as a potential code reviewer. We design our tool using client-server architecture, and then package the solution as a Google Chrome plug-in. Once the developer initiates a new pull request at GitHub, our tool automatically analyzes the request, mines two relevant histories, and then returns a ranked list of appropriate code reviewers for the request within the browser's context. Demo: https://www.youtube.com/watch?v=rXU1wTD6QQ0 },
address = {New York, NY, USA},
author = {{Authors: Mohammad Masudur Rahman Chanchal K. Roy}, Jesse Redl Jason A Collins and Rahman, Mohammad Masudur and Roy, Chanchal K and Redl, Jesse and Collins, Jason A},
doi = {10.1145/2970276.2970283},
isbn = {9781450338455},
journal = {Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering},
keywords = {,Code reviewer recommendation,GitHub,cross-project experience,pull request,specialized technology experience},
pages = {792--797},
publisher = {Association for Computing Machinery},
series = {ASE 2016},
title = {{CORRECT: Code Reviewer Recommendation at GitHub for Vendasta Technologies}},
url = {https://doi.org/10.1145/2970276.2970283},
year = {2016}
}
@article{10.1007/s11390-015-1577-3,
author = {Chen, Jing JiangJia-Huan HeXue-Yuan},
doi = {10.1007/s11390-015-1577-3},
journal = {Journal of Computer Science and Technology},
number = {5},
title = {{CoreDevRec: Automatic Core Member Recommendation for Contribution Evaluation}},
url = {http://link.springer.com/article/10.1007/s11390-015-1577-3},
volume = {30},
year = {2015}
}

680
experiment/study-search/papers-4.bib Normal file
View File

@ -0,0 +1,680 @@
@inproceedings{9054794,
abstract = {Code review is a common process that is used by developers, in which a reviewer provides useful comments or points out defects in the submitted source code changes via pull request. Code review has been widely used for both industry and open-source projects due to its capacity in early defect identification, project maintenance, and code improvement. With rapid updates on project developments, code review becomes a non-trivial and labor-intensive task for reviewers. Thus, an automated code review engine can be beneficial and useful for project development in practice. Although there exist prior studies on automating the code review process by adopting static analysis tools or deep learning techniques, they often require external sources such as partial or full source code for accurate review suggestion. In this paper, we aim at automating the code review process only based on code changes and the corresponding reviews but with better performance. The hinge of accurate code review suggestion is to learn good representations for both code changes and reviews. To achieve this with limited source, we design a multi-level embedding (i.e., word embedding and character embedding) approachto represent the semantics provided by code changes and reviews. The embeddings are then well trained through a proposed attentional deep learning model, as a whole named CORE. We evaluate the effectiveness of CORE on code changes and reviews collected from 19 popular Java projects hosted on Github. Experimental results show that our model CORE can achieve significantly better performance than the state-of-the-art model (DeepMem), with an increase of 131.03{\%} in terms of Recall@10 and 150.69{\%} in terms of Mean Reciprocal Rank. Qualitative general word analysis among project developers also demonstrates the performance of CORE in automating code review.},
author = {Siow, J K and Gao, C and Fan, L and Chen, S and Liu, Y},
booktitle = {2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER48275.2020.9054794},
issn = {1534-5351},
keywords = {,CORE,Java,attentional deep learning model,automated code review engine,automating code review,automating review recommendation,code improvement,code review suggestion,learning (artificial intelligence),mean reciprocal rank,neural nets,open-source projects,program diagnostics,project development,public domain software,pull request,qualitative general word analysis,software engineering,source code (software),source code changes},
pages = {284--295},
title = {{CORE: Automating Review Recommendation for Code Changes}},
year = {2020}
}
@article{liao2019core,
abstract = {Pull Request (PR) is a major contributor to external developers of open-source projects in GitHub. PR reviewing is an important part of open-source software developments to ensure the quality of project. Recommending suitable candidates of reviewer to the new PRs will},
author = {Liao, Zhifang and Wu, ZeXuan and Li, Yanbing and Zhang, Yan and Fan, Xiaoping and Wu, Jinsong},
journal = {Soft Computing},
pages = {1--11},
publisher = {Springer},
title = {{Core-reviewer recommendation based on Pull Request topic model and collaborator social network}},
url = {https://link.springer.com/content/pdf/10.1007/s00500-019-04217-7.pdf},
year = {2019}
}
@inproceedings{6976106,
abstract = {Continuous integration is a software engineering practice of frequently merging all developer working copies with a shared main branch, e.g., several times a day. With the advent of GitHub, a platform well known for its "social coding" features that aid collaboration and sharing, and currently the largest code host in the open source world, collaborative software development has never been more prominent. In GitHub development one can distinguish between two types of developer contributions to a project: direct ones, coming from a typically small group of developers with write access to the main project repository, and indirect ones, coming from developers who fork the main repository, update their copies locally, and submit pull requests for review and merger. In this paper we explore how GitHub developers use continuous integration as well as whether the contribution type (direct versus indirect) and different project characteristics (e.g., main programming language, or project age) are associated with the success of the automatic builds.},
author = {Vasilescu, B and van Schuylenburg, S and Wulms, J and Serebrenik, A and van den Brand, M G J},
booktitle = {2014 IEEE International Conference on Software Maintenance and Evolution},
doi = {10.1109/ICSME.2014.62},
issn = {1063-6773},
keywords = {public domain software;software engineering;source code (software);project characteristics;continuous integration;project repository;GitHub development;collaborative software development;open source world;code host;software engineering practice;social-coding world;Java;Open source software;Encoding;Blogs;Programming;continuous integration;automatic build;GitHub;collaborative software development},
pages = {401--405},
title = {{Continuous Integration in a Social-Coding World: Empirical Evidence from GitHub}},
year = {2014}
}
@article{kim2017construction,
abstract = {GitHub is the most widely used collaborative coding platform for open source project development. In GitHub, a pull-based development model is used for supporting collaboration among developers. In the pull-based development model, developers can},
author = {Kim, Jungil and Park, Sunbin and Choi, Geunho and Lee, Eunjoo},
journal = {International Information Institute (Tokyo). Information},
number = {9A},
pages = {6377--6384},
publisher = {International Information Institute},
title = {{Construction of Pull Request Contribution Graph for Assessing Developer Contributions to Pull Requests in GitHub}},
url = {http://search.proquest.com/openview/63bf755628cd24e8f15d459cda43edd7/1?pq-origsite=gscholar{\&}cbl=936334},
volume = {20},
year = {2017}
}
@inproceedings{10.1145/3183428.3183437,
abstract = {On GitHub, contributing to a new project is crucial for a developer to gain personal growth and maximize impact in the community. It is known that female developers are often hesitant to explore the opportunities to contribute to new projects even when they possess the competence to make valuable contributions. Drawing from the literature of the competence-confidence gap, we develop a fresh explanation for this phenomenon. We validate the theoretical explanation through an empirical study using GitHub's historical data. In this study, we identify all female developers ranking in top 5,000 GitHub users. Using the Granger Causality Test, we find that, for the majority of identified female developers, initiating a pull request to a new repository is "Granger" caused by the quick increase of followers in the preceding couple of weeks. For most male developers, our observations show that their new pull requests have no relationship with the dynamics of follower numbers. The results indicate that the competence-confidence gap is a threat to female developers' contribution on GitHub. The research suggests that helping female developers to overcome the competence-confidence gap is critical for encouraging female's contribution open source development, as well as growing their reputations and impacts in the community.},
address = {New York, NY, USA},
author = {Wang, Zhendong and Wang, Yi and Redmiles, David},
booktitle = {Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Society},
doi = {10.1145/3183428.3183437},
isbn = {9781450356619},
keywords = { competence-confidence gap, female developers, granger causality,github},
pages = {81--90},
publisher = {Association for Computing Machinery},
series = {ICSE-SEIS '18},
title = {{Competence-Confidence Gap: A Threat to Female Developers' Contribution on Github}},
url = {https://doi.org/10.1145/3183428.3183437},
year = {2018}
}
@article{10.1007/s00450-016-0338-z,
author = {Leymann, Johannes WettingerUwe Breitenb{\"{u}}cherMichael FalkenthalFrank},
doi = {10.1007/s00450-016-0338-z},
journal = {Computer Science - Research and Development},
number = {3 - 4},
title = {{Collaborative gathering and continuous delivery of DevOps solutions through repositories}},
url = {http://link.springer.com/article/10.1007/s00450-016-0338-z},
volume = {32},
year = {2017}
}
@inproceedings{8530075,
abstract = {Mobile app developers often need to create variants to account for different customer segments, payment models or functionalities. A common strategy is to clone (or fork) an existing app and then adapt it to new requirements. This form of reuse has been enhanced with the advent of social-coding platforms such as Github, cultivating a more systematic reuse. Different facilities, such as forks, pull requests, and cross-project traceability support clone-based development. Unfortunately, even though, many apps are known to be maintained in many variants, little is known about how practitioners manage variants of mobile apps. We present a study that explores clone-based reuse practices for open-source Android apps. We identified and analyzed families of apps that are maintained together and that exist both on the official app store (Google Play) as well as on Github, allowing us to analyze reuse practices in depth. We mined both repositories to identify app families and to study their characteristics, including their variabilities as well as code-propagation practices and maintainer relationships. We found that, indeed, app families exist and that forked app variants fall into the following categories: (i) re-branding and simple customizations, (ii) feature extension, (iii) supporting of the mainline app, and (iv) implementation of different, but related features. Other notable characteristic of the app families we discovered include: (i) 72.7{\%} of the app families did not perform any form of code propagation, and (ii) 74{\%} of the app families we studied do not have common maintainers.},
author = {Businge, J and Openja, M and Nadi, S and Bainomugisha, E and Berger, T},
booktitle = {2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)},
doi = {10.1109/ICSME.2018.00072},
issn = {2576-3148},
keywords = {,Android (operating system),App families,Cloning,Ecosystems,Github forks,Google,Measurement,Open source software,Software reusability,Systematics,clone-based reuse practices,clone-based variability management,code propagation,cross-project traceability support clone-based development,customer segments,data mining,feature extension,forked app variants,mainline app,mobile app developers,mobile apps,mobile computing,official app store,open-source Android apps,smart phones,software ecosystems,software engineering,software reuse,software variants,systematic reuse},
pages = {625--634},
title = {{Clone-Based Variability Management in the Android Ecosystem}},
year = {2018}
}
@article{10.1007/s10515-018-0238-5,
author = {Lawall, Krishna NarasimhanChristoph ReichenbachJulia},
doi = {10.1007/s10515-018-0238-5},
journal = {Automated Software Engineering},
number = {3},
title = {{Cleaning up copy–paste clones with interactive merging}},
url = {http://link.springer.com/article/10.1007/s10515-018-0238-5},
volume = {25},
year = {2018}
}
@article{10.1007/s10664-019-09798-3,
author = {Malavolta, Teerath DasMassimiliano Di PentaIvano},
doi = {10.1007/s10664-019-09798-3},
journal = {Empirical Software Engineering},
number = {4},
title = {{Characterizing the evolution of statically-detectable performance issues of Android apps}},
url = {http://link.springer.com/article/10.1007/s10664-019-09798-3},
volume = {25},
year = {2020}
}
@inproceedings{DBLP:conf/kbse/MirhosseiniP17,
author = {Mirhosseini, Samim and Parnin, Chris},
booktitle = {Proceedings of the 32nd {\{}IEEE/ACM{\}} International Conference on Automated Software Engineering, {\{}ASE{\}} 2017, Urbana, IL, USA, October 30 - November 03, 2017},
doi = {10.1109/ASE.2017.8115621},
editor = {Rosu, Grigore and Penta, Massimiliano Di and Nguyen, Tien N},
pages = {84--94},
publisher = {{\{}IEEE{\}} Computer Society},
title = {{Can automated pull requests encourage software developers to upgrade out-of-date dependencies?}},
url = {https://doi.org/10.1109/ASE.2017.8115621},
year = {2017}
}
@inproceedings{Carvalho2020,
abstract = {Static analysis tools are frequently used to detect common programming mistakes or bad practices. Yet, the existing literature reports that these tools are still underused in the industry, which is partly due to (1) the frequent high number of false positives generated, (2) the lack of automated repairing solutions, and (3) the possible mismatches between tools and workflows of development teams. In this study we explored the question: “How could a bot-based approach allow seamless integration of static analysis tools into developers' workflows?” To this end we introduce C-3PR, an event-based bot infrastructure that automatically proposes fixes to static analysis violations through pull requests (PRs). We have been using C-3PR in an industrial setting for a period of eight months. To evaluate C-3PR usefulness, we monitored its operation in response to 2179 commits to the code base of the tracked projects. The bot autonomously executed 201346 analyses, yielding 610 pull requests. Among them, 346 (57{\%}) were merged into the projects' code bases. We observed that, on average, these PRs are evaluated faster than general-purpose PRs (2.58 and 5.78 business days, respectively). Accepted transformations take even shorter time (1.56 days). Among the reasons for rejection, bugs in C-3PR and in the tools it uses are the most common ones. PRs that require the resolution of a merge conflict are almost always rejected as well. We also conducted a focus group to assess how C-3PR affected the development workflow. We observed that developers perceived C-3PR as efficient, reliable, and useful. For instance, the participants mentioned that, given the chance, they would keep using C-3PR. Our findings bring new evidence that a bot-based infrastructure could mitigate some challenges that hinder the wide adoption of static analysis tools.},
author = {Carvalho, A and Luz, W and Marc{\'{i}}lio, D and Bonif{\'{a}}cio, R and Pinto, G and Canedo, E Dias},
booktitle = {2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER48275.2020.9054842},
isbn = {1534-5351 VO -},
keywords = {C-3PR,bots in software engineering,development workflow,event-based bot infrastructure,program debugging,program diagnostics,program manipulation tools,programming mistake detectinon,pull requests,software agents,software tools,static analysis,static analysis tools},
pages = {161--171},
title = {{C-3PR: A Bot for Fixing Static Analysis Violations via Pull Requests}},
year = {2020}
}
@article{arXiv:2004.08846,
abstract = {Abstract: Bug Localization is the process of locating potential error-prone files or methods from a given bug report and source code. There is extensive research on bug localization in the literature that focuses on applying information retrieval techniques or machine learning/deep learning approaches or both, to detect location of bugs. The common premise for all approaches is the availability of a good dataset, which in this case, is the standard benchmark dataset that comprises of 6 Java projects and in some cases, more than 6 Java projects. The existing dataset do not comprise projects of other programming languages, despite of the need to investigate specific and cross project bug localization. To the best of our knowledge, we are not aware of any dataset that addresses this concern. In this paper, we present BuGL, a large-scale cross-language dataset. BuGL constitutes of more than 10,000 bug reports drawn from open-source projects written in four programming languages, namely C, C++, Java, and Python. The dataset consists of information which includes Bug Reports and Pull-Requests. BuGL aims to unfold new research opportunities in the area of bug localization. △ Less},
author = {{Authors: Sandeep Muvva A Eashaan Rao}, Sridhar Chimalakonda},
journal = {arXiv preprint arXiv:2004.08846},
title = {{BuGL -- A Cross-Language Dataset for Bug Localization}},
year = {2020}
}
@article{golzadehbot,
abstract = {Many empirical studies focus on socio-technical activity in social coding platforms such as GitHub, for example to study the onboarding, abandonment, productivity and collaboration among team members. Such studies face the difficulty that GitHub activity can also be},
author = {Golzadeh, Mehdi and Legay, Damien and Decan, Alexandre and Mens, Tom},
journal = {ICSEW},
title = {{Bot or not? Detecting bots in GitHub pull request activity based on comment similarity}},
url = {http://mehdigolzadeh.com/research/BotSE{\_}paper.pdf}
}
@inproceedings{10.1109/ICSE-SEIS.2019.17,
abstract = {Developers in open source projects must make decisions on contributions from other community members, such as whether or not to accept a pull request. However, secondary factors---beyond the code itself---can influence those decisions. For example, signals from GitHub profiles, such as a number of followers, activity, names, or gender can also be considered when developers make decisions. In this paper, we examine how developers use these signals (or not) when making decisions about code contributions. To evaluate this question, we evaluate how signals related to perceived gender identity and code quality influenced decisions on accepting pull requests. Unlike previous work, we analyze this decision process with data collected from an eye-tracker. We analyzed differences in what signals developers said are important for themselves versus what signals they actually used to make decisions about others. We found that after the code snippet (x = 57{\%}), the second place programmers spent their time ixating is on supplemental technical signals (x = 32{\%}), such as previous contributions and popular repositories. Diverging from what participants reported themselves, we also found that programmers ixated on social signals more than recalled.},
author = {Ford, Denae and Behroozi, Mahnaz and Serebrenik, Alexander and Parnin, Chris},
booktitle = {Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Society, {\{}ICSE{\}} 2019, Montreal, QC, Canada, May 25-31, 2019},
doi = {10.1109/ICSE-SEIS.2019.17},
editor = {Kazman, Rick and Pasquale, Liliana},
keywords = {,code contributions,eye-tracking,open source software development,socio-technical ecosystems,transparency},
pages = {51--60},
publisher = {ACM},
series = {ICSE-SEIS '19},
title = {{Beyond the Code Itself: How Programmers {\textless}i{\textgreater}Really{\textless}/i{\textgreater} Look at Pull Requests}},
url = {https://doi.org/10.1109/ICSE-SEIS.2019.17 https://doi.org/10.1109/ICSE-SEIS.2019.00014},
year = {2019}
}
@article{10.1145/3350768.3350788,
abstract = {Abstract: Recently, GitHub introduced a new social feature, named reactions, which are "pictorial characters" similar to emoji symbols widely used nowadays in text-based communications. Particularly, GitHub users can use a pre-defined set of such symbols to react to issues and pull requests. However, little is known about the real usage and impact of GitHub reactions. In this paper, we analyze the reactions provided by developers to more than 2.5 million issues and 9.7 million issue comments, in order to answer an extensive list of nine research questions about the usage and adoption of reactions. We show that reactions are being increasingly used by open source developers. Moreover, we also found that issues with reactions usually take more time to be handled and have longer discussions. △ Less},
address = {New York, NY, USA},
author = {{Authors: Hudson Borges Rodrigo Brito}, Marco Tulio Valente and Borges, Hudson and Brito, Rodrigo and Valente, Marco Tulio},
doi = {10.1145/3350768.3350788},
isbn = {9781450376518},
journal = {arXiv preprint arXiv:1910.00188},
keywords = {,GitHub,Reactions,Social Coding},
pages = {397--406},
publisher = {Association for Computing Machinery},
series = {SBES 2019},
title = {{Beyond Textual Issues: Understanding the Usage and Impact of GitHub Reactions}},
url = {https://doi.org/10.1145/3350768.3350788},
year = {2019}
}
@inproceedings{8667991,
abstract = {Benchmarks of bugs are essential to empirically evaluate automatic program repair tools. In this paper, we present BEARS, a project for collecting and storing bugs into an extensible bug benchmark for automatic repair studies in Java. The collection of bugs relies on commit building state from Continuous Integration (CI) to find potential pairs of buggy and patched program versions from open-source projects hosted on GitHub. Each pair of program versions passes through a pipeline where an attempt of reproducing a bug and its patch is performed. The core step of the reproduction pipeline is the execution of the test suite of the program on both program versions. If a test failure is found in the buggy program version candidate and no test failure is found in its patched program version candidate, a bug and its patch were successfully reproduced. The uniqueness of Bears is the usage of CI (builds) to identify buggy and patched program version candidates, which has been widely adopted in the last years in open-source projects. This approach allows us to collect bugs from a diversity of projects beyond mature projects that use bug tracking systems. Moreover, BEARS was designed to be publicly available and to be easily extensible by the research community through automatic creation of branches with bugs in a given GitHub repository, which can be used for pull requests in the BEARS repository. We present in this paper the approach employed by BEARS, and we deliver the version 1.0 of BEARS, which contains 251 reproducible bugs collected from 72 projects that use the Travis CI and Maven build environment.},
author = {Madeiral, F and Urli, S and Maia, M and Monperrus, M},
booktitle = {2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)},
doi = {10.1109/SANER.2019.8667991},
issn = {1534-5351},
keywords = {Java;program debugging;program testing;public domain software;buggy program version candidate;test failure;patched program version candidate;open-source projects;bug tracking systems;BEARS;251 reproducible bugs;extensible Java bug benchmark;automatic program repair studies;automatic program repair tools;extensible bug benchmark;patched program versions;bug storage;GitHub;Computer bugs;Benchmark testing;Maintenance engineering;Tools;Java;Open source software;Pipelines},
pages = {468--478},
title = {{BEARS: An Extensible Java Bug Benchmark for Automatic Program Repair Studies}},
year = {2019}
}
@article{7328331,
abstract = {Code review is an important part of the software development process. Recently, many open source projects have begun practicing code review through “modern” tools such as GitHub pull-requests and Gerrit. Many commercial software companies use similar tools for code review internally. These tools enable the owner of a source code change to request individuals to participate in the review, i.e., reviewers. However, this task comes with a challenge. Prior work has shown that the benefits of code review are dependent upon the expertise of the reviewers involved. Thus, a common problem faced by authors of source code changes is that of identifying the best reviewers for their source code change. To address this problem, we present an approach, namely cHRev, to automatically recommend reviewers who are best suited to participate in a given review, based on their historical contributions as demonstrated in their prior reviews. We evaluate the effectiveness of cHRev on three open source systems as well as a commercial codebase at Microsoft and compare it to the state of the art in reviewer recommendation. We show that by leveraging the specific information in previously completed reviews (i.e.,quantification of review comments and their recency), we are able to improve dramatically on the performance of prior approaches, which (limitedly) operate on generic review information (i.e., reviewers of similar source code file and path names) or source coderepository data. We also present the insights into why our approach cHRev outperforms the existing approaches.},
author = {Zanjani, M B and Kagdi, H and Bird, C},
doi = {10.1109/TSE.2015.2500238},
issn = {1939-3520},
journal = {IEEE Transactions on Software Engineering},
keywords = {software engineering;software reviews;peer reviewer recommendation;code review;software development process;open source projects;GitHub pull-requests tool;Gerrit tool;source code change;cHRev approach;commercial codebase;History;Electronic mail;Birds;Inspection;Androids;Humanoid robots;Software;Modern code review;reviewer recommendation;code change;Gerrit;Modern code review;reviewer recommendation;code change;Gerrit},
number = {6},
pages = {530--543},
title = {{Automatically Recommending Peer Reviewers in Modern Code Review}},
volume = {42},
year = {2016}
}
@inproceedings{8930842,
abstract = {Static code analysis tools such as FindBugs and SonarQube are widely used on open-source and industrial projects to detect a variety of issues that may negatively affect the quality of software. Despite these tools' popularity and high level of automation, several empirical studies report that developers normally fix only a small fraction (typically, less than 10{\%} [1]) of the reported issues-so-called "warnings". If these analysis tools could also automatically provide suggestions on how to fix the issues that trigger some of the warnings, their feedback would become more actionable and more directly useful to developers. In this work, we investigate whether it is feasible to automatically generate fix suggestions for common warnings issued by static code analysis tools, and to what extent developers are willing to accept such suggestions into the codebases they're maintaining. To this end, we implemented a Java program transformation technique that fixes 11 distinct rules checked by two well-known static code analysis tools (SonarQube and SpotBugs). Fix suggestions are generated automatically based on templates, which are instantiated in a way that removes the source of the warnings; templates for some rules are even capable of producing multi-line patches. We submitted 38 pull requests, including 920 fixes generated automatically by our technique for various open-source Java projects, including the Eclipse IDE and both SonarQube and SpotBugs tools. At the time of writing, project maintainers accepted 84{\%} of our fix suggestions (95{\%} of them without any modifications). These results indicate that our approach to generating fix suggestions is feasible, and can help increase the applicability of static code analysis tools.},
author = {Marcilio, D and Furia, C A and Bonif{\'{a}}cio, R and Pinto, G},
booktitle = {2019 19th International Working Conference on Source Code Analysis and Manipulation (SCAM)},
doi = {10.1109/SCAM.2019.00013},
issn = {2470-6892},
keywords = {Java;program debugging;program diagnostics;program verification;public domain software;software maintenance;software quality;static code analysis warnings;static code analysis tools;fix suggestions;open-source projects;industrial projects;Java program transformation;SpotBugs tools;SonarQube tools;Tools;Computer bugs;Java;Static analysis;Open source software;Syntactics;Static Analysis Tools;Program Repair;Program Transformation},
pages = {34--44},
title = {{Automatically Generating Fix Suggestions in Response to Static Code Analysis Warnings}},
year = {2019}
}
@article{arXiv:1811.08330,
abstract = {Abstract: In the literature, there is a rather clear segregation between manually written tests by developers and automatically generated ones. In this paper, we explore a third solution: to automatically improve existing test cases written by developers. We present the concept, design, and implementation of a system called $\backslash$dspot, that takes developer-written test cases as input (junit tests in Java) and synthesizes improved versions of them as output. Those test improvements are given back to developers as patches or pull requests, that can be directly integrated in the main branch of the test code base. We have evaluated DSpot in a deep, systematic manner over 40 real-world unit test classes from 10 notable and open-source software projects. We have amplified all test methods from those 40 unit test classes. In 26/40 cases, DSpot is able to automatically improve the test under study, by triggering new behaviors and adding new valuable assertions. Next, for ten projects under consideration, we have proposed a test improvement automatically synthesized by $\backslash$dspot to the lead developers. In total, 13/19 proposed test improvements were accepted by the developers and merged into the main code base. This shows that DSpot is capable of automatically improving unit-tests in real-world, large-scale Java software. △ Less},
author = {{Authors: Benjamin Danglot Oscar Luis Vera-P{\'{e}}rez}, Benoit Baudry Martin Monperrus},
doi = {10.1007/s10664-019-09692-y},
journal = {arXiv preprint arXiv:1811.08330},
title = {{Automatic Test Improvement with DSpot: a Study with Ten Mature Open-Source Projects}},
year = {2018}
}
@article{10.1007/s10664-019-09692-y,
author = {Monperrus, Benjamin DanglotOscar Luis Vera-P{\'{e}}rezBenoit BaudryMartin},
doi = {10.1007/s10664-019-09692-y},
journal = {Empirical Software Engineering},
number = {4},
title = {{Automatic test improvement with DSpot: a study with ten mature open-source projects}},
url = {http://link.springer.com/article/10.1007/s10664-019-09692-y},
volume = {24},
year = {2019}
}
@article{brazdilautomatic,
abstract = {I would like to thank V{\'{a}}clav Tunka, my technical advisor and my colleague, for consultations and motivation and also for language correction. I am also grateful to Filip Nguyen for valuable advice. To Kohsuke Kawaguchi I am grateful for accepting my Pull Requests. Also I would like},
author = {Brazdil, Jan},
title = {{Automatic Pull Request Integration}},
url = {https://is.muni.cz/th/374346/fi{\_}b/bakalarka{\_}{\_}1{\_}.pdf}
}
@inproceedings{10.1109/ASE.2019.00026,
abstract = {Enabled by the pull-based development model, developers can easily contribute to a project through pull requests (PRs). When creating a PR, developers can add a free-form description to describe what changes are made in this PR and/or why. Such a description is helpful for reviewers and other developers to gain a quick understanding of the PR without touching the details and may reduce the possibility of the PR being ignored or rejected. However, developers sometimes neglect to write descriptions for PRs. For example, in our collected dataset with over 333K PRs, more than 34{\%} of the PR descriptions are empty. To alleviate this problem, we propose an approach to automatically generate PR descriptions based on the commit messages and the added source code comments in the PRs. We regard this problem as a text summarization problem and solve it using a novel sequence-to-sequence model. To cope with out-of-vocabulary words in software artifacts and bridge the gap between the training loss function of the sequence-to-sequence model and the evaluation metric ROUGE, which has been shown to correspond to human evaluation, we integrate the pointer generator and directly optimize for ROUGE using reinforcement learning and a special loss function. We build a dataset with over 41K PRs and evaluate our approach on this dataset through ROUGE and a human evaluation. Our evaluation results show that our approach outperforms two baselines by significant margins.},
author = {Liu, Zhongxin and Xia, Xin and Treude, Christoph and Lo, David and Li, Shanping},
booktitle = {Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering},
doi = {10.1109/ASE.2019.00026},
isbn = {9781728125084},
pages = {176--188},
publisher = {IEEE Press},
series = {ASE '19},
title = {{Automatic Generation of Pull Request Descriptions}},
url = {https://doi.org/10.1109/ASE.2019.00026},
year = {2019}
}
@inproceedings{DBLP:conf/sofsem/FreireBF18,
author = {{da C. Luna Freire}, Victor and Brunet, Jo{\~{a}}o and de Figueiredo, Jorge C A},
booktitle = {{\{}SOFSEM{\}} 2018: Theory and Practice of Computer Science - 44th International Conference on Current Trends in Theory and Practice of Computer Science, Krems, Austria, January 29 - February 2, 2018, Proceedings},
doi = {10.1007/978-3-319-73117-9_18},
editor = {Tjoa, A Min and Bellatreche, Ladjel and Biffl, Stefan and van Leeuwen, Jan and Wiedermann, Jir$\backslash$'$\backslash$i},
pages = {255--268},
publisher = {Springer},
series = {Lecture Notes in Computer Science},
title = {{Automatic Decomposition of Java Open Source Pull Requests: {\{}A{\}} Replication Study}},
url = {https://doi.org/10.1007/978-3-319-73117-9{\_}18},
volume = {10706},
year = {2018}
}
@inproceedings{DBLP:conf/seke/LiYYWFW17,
author = {Li, Zhixing and Yu, Yue and Yin, Gang and Wang, Tao and Fan, Qiang and Wang, Huaimin},
booktitle = {The 29th International Conference on Software Engineering and Knowledge Engineering, Wyndham Pittsburgh University Center, Pittsburgh, PA, USA, July 5-7, 2017},
doi = {10.18293/SEKE2017-039},
editor = {He, Xudong},
pages = {572--577},
publisher = {{\{}KSI{\}} Research Inc. and Knowledge Systems Institute Graduate School},
title = {{Automatic Classification of Review Comments in Pull-based Development Model}},
url = {https://doi.org/10.18293/SEKE2017-039},
year = {2017}
}
@article{DBLP:journals/jss/JuniorSPM18,
author = {{de Lima J{\'{u}}nior}, Manoel Limeira and Soares, Daric{\'{e}}lio Moreira and Plastino, Alexandre and Murta, Leonardo},
doi = {10.1016/j.jss.2018.05.065},
journal = {J. Syst. Softw.},
pages = {181--196},
title = {{Automatic assignment of integrators to pull requests: The importance of selecting appropriate attributes}},
url = {https://doi.org/10.1016/j.jss.2018.05.065},
volume = {144},
year = {2018}
}
@article{10.1007/s10664-018-9676-8,
author = {Bacchelli, Tobias BaumKurt SchneiderAlberto},
doi = {10.1007/s10664-018-9676-8},
journal = {Empirical Software Engineering},
number = {4},
title = {{Associating working memory capacity and code change ordering with code review performance}},
url = {http://link.springer.com/article/10.1007/s10664-018-9676-8},
volume = {24},
year = {2019}
}
@inproceedings{10.1109/MSR.2017.34,
abstract = {As the software development community makes it easier to contribute to open source projects, the number of commits and pull requests keep increasing. However, this exciting growth renders it more difficult to only accept quality contributions. Recent research has found that both technical and social factors predict the success of project contributions on GitHub. We take this question a step further, focusing on predicting continuous integration build success based on technical and social factors involved in a commit. Specifically, we investigated if social factors (such as being a core member of the development team, having a large number of followers, or contributing a large number of commits) improve predictions of build success. We found that social factors cause a noticeable increase in predictive power (12{\%}), core team members are more likely to pass the build tests (10{\%}), and users with 1000 or more followers are more likely to pass the build tests (10{\%}).},
author = {Soto, Mauricio and Coker, Zack and Goues, Claire Le},
booktitle = {Proceedings of the 14th International Conference on Mining Software Repositories},
doi = {10.1109/MSR.2017.34},
isbn = {9781538615447},
keywords = { GitHub, Travis CI, social attributes, social coding, social networks,predicting integration success},
pages = {483--486},
publisher = {IEEE Press},
series = {MSR '17},
title = {{Analyzing the Impact of Social Attributes on Commit Integration Success}},
url = {https://doi.org/10.1109/MSR.2017.34},
year = {2017}
}
@inproceedings{10.1145/3306446.3340825,
abstract = {The network of collaborations in an open source project can reveal relevant emergent properties that influence its prospects of success. In this work, we analyze open source projects to determine whether they exhibit a rich-club behavior, i.e., a phenomenon where contributors with a high number of collaborations (i.e., strongly connected within the collaboration network) are likely to cooperate with other well-connected individuals. The presence or absence of a rich-club has an impact on the sustainability and robustness of the project.For this analysis, we build and study a dataset with the 100 most popular projects in GitHub, exploiting connectivity patterns in the graph structure of collaborations that arise from commits, issues and pull requests. Results show that rich-club behavior is present in all the projects, but only few of them have an evident club structure. We compute coefficients both for single source graphs and the overall interaction graph, showing that rich-club behavior varies across different layers of software development. We provide possible explanations of our results, as well as implications for further analysis.},
address = {New York, NY, USA},
author = {Gasparini, Mattia and Izquierdo, Javier Luis C{\'{a}}novas and Claris{\'{o}}, Robert and Brambilla, Marco and Cabot, Jordi},
booktitle = {Proceedings of the 15th International Symposium on Open Collaboration},
doi = {10.1145/3306446.3340825},
isbn = {9781450363198},
keywords = { network analysis, open source, rich-club coefficient,GitHub},
publisher = {Association for Computing Machinery},
series = {OpenSym '19},
title = {{Analyzing Rich-Club Behavior in Open Source Projects}},
url = {https://doi.org/10.1145/3306446.3340825},
year = {2019}
}
@article{10.1007/s10664-018-9666-x,
author = {Gheyi, Fl{\'{a}}vio MedeirosGabriel LimaGuilherme AmaralSven ApelChristian K{\"{a}}stnerM{\'{a}}rcio RibeiroRohit},
doi = {10.1007/s10664-018-9666-x},
journal = {Empirical Software Engineering},
number = {4},
title = {{An investigation of misunderstanding code patterns in C open-source software projects}},
url = {http://link.springer.com/article/10.1007/s10664-018-9666-x},
volume = {24},
year = {2019}
}
@article{DBLP:journals/corr/abs-1807-01853,
abstract = {Abstract: Given the increasing number of unsuccessful pull requests in GitHub projects, insights into the success and failure of these requests are essential for the developers. In this paper, we provide a comparative study between successful and unsuccessful pull requests made to 78 GitHub base projects by 20,142 developers from 103,192 forked projects. In the study, we analyze pull request discussion texts, project specific information (e.g., domain, maturity), and developer specific information (e.g., experience) in order to report useful insights, and use them to contrast between successful and unsuccessful pull requests. We believe our study will help developers overcome the issues with pull requests in GitHub, and project administrators with informed decision making. △ Less},
address = {New York, NY, USA},
archivePrefix = {arXiv},
arxivId = {1807.01853},
author = {Rahman, Mohammad Masudur and Roy, Chanchal K and {Authors: Mohammad Masudur Rahman}, Chanchal K Roy},
doi = {10.1145/2597073.2597121},
eprint = {1807.01853},
isbn = {9781450328630},
journal = {CoRR},
keywords = {,Commit comments,pull request,topic model},
pages = {364--367},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{An Insight into the Pull Requests of GitHub}},
url = {http://arxiv.org/abs/1807.01853 https://doi.org/10.1145/2597073.2597121},
volume = {abs/1807.01853},
year = {2014}
}
@article{10.1007/s10664-015-9393-5,
author = {Damian, Eirini KalliamvakouGeorgios GousiosKelly BlincoeLeif SingerDaniel M GermanDaniela},
doi = {10.1007/s10664-015-9393-5},
journal = {Empirical Software Engineering},
number = {5},
title = {{An in-depth study of the promises and perils of mining GitHub}},
url = {http://link.springer.com/article/10.1007/s10664-015-9393-5},
volume = {21},
year = {2016}
}
@article{10.1007/s10664-019-09700-1,
abstract = {Social coding enables collaborative software development in virtual and distributed communities. Social coding platforms (e.g., GITHUB) provide the pull request feature that allows developers to clone a project, make code changes, and request the project owners to review and integrate the code changes to the main stream of a project. The pull request feature has been widely adopted by a large number of GITHUB projects, as it minimizes the risk of exposing the projects to the open communities. The efficiency of the pull requests review process depends both on technical (e.g., the code quality) and social (e.g., the connection of a contributor to the project maintainer) factors. However, it is still unclear which social factors have the most impact on the efficiency of the review process. To identify the social factors, we study the team structures formed by the developers within the projects that adopt the pull-based development model. We build the pull-based networks, where two developers are linked if one has integrated a pull request submitted by the other. We investigate the 7,850 most popular projects on GITHUB that are developed in ten programming languages. We identify the network metrics that have a significant association with the speed of processing the pull requests. Specifically, maintaining a strong core of contributors and denser interactions among the developers is associated with faster response and processing of the pull requests. We further find that more than 90{\%} of the studied projects follow 8 dominant team structures out of 18 possible team structures. In the larger projects, only a set of developers is granted review and integration privileges of the pull requests, reflecting a strict decision making process. The small to medium projects are characterized by a small number of core contributors who maintain repeated interactions, and are able to process the incoming pull requests more efficiently. The evolution of the team structures of projects over time reveals that only a low percentage of the projects witnesses a change towards team structures associated to faster pull requests processing (e.g., stronger centralization).},
author = {Zou, Mariam El MezouarFeng ZhangYing},
doi = {10.1007/s10664-019-09700-1},
journal = {Empirical Software Engineering},
number = {6},
title = {{An empirical study on the teams structures in social coding using GitHub projects}},
url = {http://link.springer.com/article/10.1007/s10664-019-09700-1},
volume = {24},
year = {2019}
}
@article{10.1007/s10664-018-9636-3,
author = {{da CostaFeng ZhangYing Zou}, Yonghui HuangDaniel Alencar},
doi = {10.1007/s10664-018-9636-3},
journal = {Empirical Software Engineering},
number = {2},
title = {{An empirical study on the issue reports with questions raised during the issue resolving process}},
url = {http://link.springer.com/article/10.1007/s10664-018-9636-3},
volume = {24},
year = {2019}
}
@inproceedings{10.1145/3213846.3213866,
abstract = {Deep learning applications become increasingly popular in important domains such as self-driving systems and facial identity systems. Defective deep learning applications may lead to catastrophic consequences. Although recent research efforts were made on testing and debugging deep learning applications, the characteristics of deep learning defects have never been studied. To fill this gap, we studied deep learning applications built on top of TensorFlow and collected program bugs related to TensorFlow from StackOverflow QA pages and Github projects. We extracted information from QA pages, commit messages, pull request messages, and issue discussions to examine the root causes and symptoms of these bugs. We also studied the strategies deployed by TensorFlow users for bug detection and localization. These findings help researchers and TensorFlow users to gain a better understanding of coding defects in TensorFlow programs and point out a new direction for future research.},
address = {New York, NY, USA},
author = {Zhang, Yuhao and Chen, Yifan and Cheung, Shing-Chi and Xiong, Yingfei and Zhang, Lu},
booktitle = {Proceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis},
doi = {10.1145/3213846.3213866},
isbn = {9781450356992},
keywords = { Deep Learning, TensorFlow Program Bug,Empirical Study},
pages = {129--140},
publisher = {Association for Computing Machinery},
series = {ISSTA 2018},
title = {{An Empirical Study on TensorFlow Program Bugs}},
url = {https://doi.org/10.1145/3213846.3213866},
year = {2018}
}
@article{10.1007/s10664-019-09695-9,
author = {{da CostaYing Zou}, Taher Ahmed GhalebDaniel Alencar},
doi = {10.1007/s10664-019-09695-9},
journal = {Empirical Software Engineering},
number = {4},
title = {{An empirical study of the long duration of continuous integration builds}},
url = {http://link.springer.com/article/10.1007/s10664-019-09695-9},
volume = {24},
year = {2019}
}
@inproceedings{DBLP:conf/internetware/YangZZFYW17,
author = {Yang, Cheng and Zhang, Xunhui and Zeng, Lingbin and Fan, Qiang and Yin, Gang and Wang, Huaimin},
booktitle = {Proceedings of the 9th Asia-Pacific Symposium on Internetware, Internetware 2017, Shanghai, China, September 23 - 23, 2017},
doi = {10.1145/3131704.3131718},
editor = {Mei, Hong and Lyu, Jian and Jin, Zhi and Zhao, Wenyun},
pages = {14:1----14:6},
publisher = {ACM},
title = {{An Empirical Study of Reviewer Recommendation in Pull-based Development Model}},
url = {https://doi.org/10.1145/3131704.3131718},
year = {2017}
}
@article{arXiv:1708.02618,
abstract = {Software ecosystems can be viewed as socio-technical networks consisting of technical components (software packages) and social components (communities of developers) that maintain the technical components. Ecosystems evolve over time through socio-technical changes that may greatly impact the ecosystem's sustainability. Social changes like developer turnover may lead to technical degradation. This motivates the need to identify those factors leading to developer abandonment, in order to automate the process of identifying developers with high abandonment risk. This paper compares such factors for two software package ecosystems, RubyGems and npm. We analyse the evolution of their packages hosted on GitHub, considering development activity in terms of commits, and social interaction with other developers in terms of comments associated to commits, issues or pull requests. We analyse this socio-technical activity for more than 30 and 60k developers for RubyGems and npm, respectively. We use survival analysis to identify which factors coincide with a lower survival probability. Our results reveal that developers with a higher probability to abandon an ecosystem: do not engage in discussions with other developers; do not have strong social and technical activity intensity; communicate or commit less frequently; and do not participate to both technical and social activities for long periods of time. Such observations could be used to automate the identification of developers with a high probability of abandoning the ecosystem and, as such, reduce the risks associated to knowledge loss.},
author = {Mens, Eleni ConstantinouTom and {Authors: Eleni Constantinou}, Tom Mens},
doi = {10.1007/s11334-017-0303-4},
journal = {arXiv preprint arXiv:1708.02618},
number = {2 - 3},
title = {{An Empirical Comparison of Developer Retention in the RubyGems and npm Software Ecosystems}},
url = {http://link.springer.com/article/10.1007/s11334-017-0303-4},
volume = {13},
year = {2017}
}
@article{10.1007/s10664-019-09794-7,
author = {Baudry, Benjamin DanglotMartin MonperrusWalter RudametkinBenoit},
doi = {10.1007/s10664-019-09794-7},
journal = {Empirical Software Engineering},
number = {4},
title = {{An approach and benchmark to detect behavioral changes of commits in continuous integration}},
url = {http://link.springer.com/article/10.1007/s10664-019-09794-7},
volume = {25},
year = {2020}
}
@article{10.1007/s10606-018-9323-3,
author = {Ignat, Hoai Le NguyenClaudia-Lavinia},
doi = {10.1007/s10606-018-9323-3},
journal = {Computer Supported Cooperative Work (CSCW)},
number = {3 - 6},
title = {{An Analysis of Merge Conflicts and Resolutions in Git-Based Open Source Projects}},
url = {http://link.springer.com/article/10.1007/s10606-018-9323-3},
volume = {27},
year = {2018}
}
@article{arXiv:2001.09630,
abstract = {Abstract: Finding and fixing buggy code is an important and cost-intensive maintenance task, and static analysis (SA) is one of the methods developers use to perform it. SA tools warn developers about potential bugs by scanning their source code for commonly occurring bug patterns, thus giving those developers opportunities to fix the warnings (potential bugs) before they release the software. Typically, SA tools scan for general bug patterns that are common to any software project (such as null pointer dereference), and not for project specific patterns. However, past research has pointed to this lack of customizability as a severe limiting issue in SA. Accordingly, in this paper, we propose an approach called Ammonia, which is based on statically analyzing changes across the development history of a project, as a means to identify project-specific bug patterns. Furthermore, the bug patterns identified by our tool do not relate to just one developer or one specific commit, they reflect the project as a whole and compliment the warnings from other SA tools that identify general bug patterns. Herein, we report on the application of our implemented tool and approach to four Java projects: Ant, Camel, POI, and Wicket. The results obtained show that our tool could detect 19 project specific bug patterns across those four projects. Next, through manual analysis, we determined that six of those change patterns were actual bugs and submitted pull requests based on those bug patterns. As a result, five of the pull requests were merged. △ Less},
author = {Nagappan, Yoshiki HigoShinpei HayashiHideaki HataMeiyappan and {Authors: Yoshiki Higo Shinpei Hayashi}, Hideaki Hata Meiyappan Nagappan},
doi = {10.1007/s10664-020-09807-w},
journal = {Empirical Software Engineering},
number = {3},
title = {{Ammonia: An Approach for Deriving Project-specific Bug Patterns}},
url = {http://link.springer.com/article/10.1007/s10664-020-09807-w},
volume = {25},
year = {2020}
}
@inproceedings{10.1145/3180155.3180208,
abstract = {Recent studies suggest that well-known OSS projects struggle to find the needed workforce to continue evolving---in part because external developers fail to overcome their first contribution barriers. In this paper, we investigate how and why quasi-contributors (external developers who did not succeed in getting their contributions accepted to an OSS project) fail. To achieve our goal, we collected data from 21 popular, non-trivial GitHub projects, identified quasi-contributors, and analyzed their pull-requests. In addition, we conducted surveys with quasi-contributors, and projects' integrators, to understand their perceptions about nonacceptance. We found 10,099 quasi-contributors --- about 70{\%} of the total actual contributors --- that submitted 12,367 nonaccepted pull-requests. In five projects, we found more quasi-contributors than actual contributors. About one-third of the developers who took our survey disagreed with the nonacceptance, and around 30{\%} declared the nonacceptance demotivated or prevented them from placing another pull-request. The main reasons for pull-request nonacceptance from the quasi-contributors' perspective were "superseded/duplicated pull-request" and "mismatch between developer's and team's vision/opinion." A manual analysis of a representative sample of 263 pull-requests corroborated with this finding. We also found reasons related to the relationship with the community and lack of experience or commitment from the quasi-contributors. This empirical study is particularly relevant to those interested in fostering developers' participation and retention in OSS communities.},
address = {New York, NY, USA},
author = {Steinmacher, Igor and Pinto, Gustavo and Wiese, Igor Scaliante and Gerosa, Marco A},
booktitle = {Proceedings of the 40th International Conference on Software Engineering},
doi = {10.1145/3180155.3180208},
isbn = {9781450356381},
keywords = { open source software, pull-requests, quasi-contributors,newcomers},
pages = {256--266},
publisher = {Association for Computing Machinery},
series = {ICSE '18},
title = {{Almost There: A Study on Quasi-Contributors in Open Source Software Projects}},
url = {https://doi.org/10.1145/3180155.3180208},
year = {2018}
}
@inproceedings{10.1145/2897000.2897001,
abstract = {Building trust among remote developers is challenging because trust typically grows through close face-to-face interaction. In this paper, we present the preparatory design of an empirical study aimed to assess whether affective trust, established through social communication between developers, is a predictor of successful collaboration in distributed projects. Specifically, we intend to measure affective trust through sentiment analysis of pull-request comments.},
address = {New York, NY, USA},
author = {Calefato, Fabio and Lanubile, Filippo},
booktitle = {Proceedings of the 1st International Workshop on Emotion Awareness in Software Engineering},
doi = {10.1145/2897000.2897001},
isbn = {9781450341691},
keywords = { distributed software projects, human factors, sentiment analysis,affective trust},
pages = {3--5},
publisher = {Association for Computing Machinery},
series = {SEmotion '16},
title = {{Affective Trust as a Predictor of Successful Collaboration in Distributed Software Projects}},
url = {https://doi.org/10.1145/2897000.2897001},
year = {2016}
}
@mastersthesis{rishi2017affective,
abstract = {Sentiment and emotional analysis on online collaborative software development forums can be very useful to gain important insights into the behaviors and personalities of the developers. Such information can later on be used to increase productivity of developers by},
author = {Rishi, Deepak},
school = {University of Waterloo},
title = {{Affective sentiment and emotional analysis of pull request comments on github}},
url = {https://uwspace.uwaterloo.ca/handle/10012/12728},
year = {2017}
}
@inproceedings{10.1145/3180155.3180209,
abstract = {In fast-paced, reuse-heavy, and distributed software development, the transparency provided by social coding platforms like GitHub is essential to decision making. Developers infer the quality of projects using visible cues, known as signals, collected from personal profile and repository pages. We report on a large-scale, mixed-methods empirical study of npm packages that explores the emerging phenomenon of repository badges, with which maintainers signal underlying qualities about their projects to contributors and users. We investigate which qualities maintainers intend to signal and how well badges correlate with those qualities. After surveying developers, mining 294,941 repositories, and applying statistical modeling and time-series analyses, we find that non-trivial badges, which display the build status, test coverage, and up-to-dateness of dependencies, are mostly reliable signals, correlating with more tests, better pull requests, and fresher dependencies. Displaying such badges correlates with best practices, but the effects do not always persist.},
address = {New York, NY, USA},
author = {Trockman, Asher and Zhou, Shurui and K{\"{a}}stner, Christian and Vasilescu, Bogdan},
booktitle = {Proceedings of the 40th International Conference on Software Engineering},
doi = {10.1145/3180155.3180209},
isbn = {9781450356381},
pages = {511--522},
publisher = {Association for Computing Machinery},
series = {ICSE '18},
title = {{Adding Sparkle to Social Coding: An Empirical Study of Repository Badges in the {\textless}i{\textgreater}Npm{\textless}/i{\textgreater} Ecosystem}},
url = {https://doi.org/10.1145/3180155.3180209},
year = {2018}
}
@inproceedings{azeem2020action,
abstract = {Pull requests (PRs) selection is a challenging task faced by integrators in pull-based development (PbD), with hundreds of PRs submitted on a daily basis to large open-source projects. Managing these PRs manually consumes integrators' time and resources and may},
author = {Azeem, Muhammad Ilyas and Panichella, Sebastiano and {Di Sorbo}, Andrea and Serebrenik, Alexander and Wang, Qing},
booktitle = {International Conference on Software and System Processes},
title = {{Action-based Recommendation in Pull-request Development}},
url = {https://www.win.tue.nl/{~}aserebre/ICSSP2020.pdf},
year = {2020}
}
@inproceedings{10.1145/2695664.2695856,
abstract = {Distributed version control systems provide support for pull request strategy, which is used to register external contributions in collaborative software projects. The data present on a pull request can provide insights of factors that have influence on the acceptance or rejection of contributions in open source projects. Furthermore, the discovery of knowledge about pull requests allows confirming or denying existing hypotheses and helps software developers and project managers to guide their actions. This work proposes the use of data mining, more specifically, the extraction of association rules, to find patterns that exert influence on the acceptance (merge) of a pull request. The results suggest that: (i) the use of association rules allows to identify which factors increase the likelihood of a pull request merge; (ii) the identification of attributes that influence the merge reveals important knowledge about the pull request model; and (iii) with the use of association rules, it is possible to determine which factors contribute to a faster merge.},
address = {New York, NY, USA},
author = {Soares, Daric{\'{e}}lio Moreira and {de Lima J{\'{u}}nior}, Manoel Limeira and Murta, Leonardo and Plastino, Alexandre},
booktitle = {Proceedings of the 30th Annual ACM Symposium on Applied Computing},
doi = {10.1145/2695664.2695856},
isbn = {9781450331968},
keywords = { association rules, data mining, software repositories,pull request},
pages = {1541--1546},
publisher = {Association for Computing Machinery},
series = {SAC '15},
title = {{Acceptance Factors of Pull Requests in Open-Source Projects}},
url = {https://doi.org/10.1145/2695664.2695856},
year = {2015}
}
@article{arXiv:1905.03593,
abstract = {Abstract: With over 28 million developers, success of the GitHub collaborative platform is highlighted through an abundance of communication channels among contemporary software projects. Knowledge is broken into two forms and its sharing (through communication channels) can be described as externalization or combination by the SECI model. Such platforms have revolutionized the way developers work, introducing new channels to share knowledge in the form of pull requests, issues and wikis. It is unclear how these channels capture and share knowledge. In this research, our goal is to analyze these communication channels in GitHub. First, using the SECI model, we are able to map how knowledge is shared through the communication channels. Then in a large-scale topology analysis of seven library package projects (i.e., involving over 70 thousand projects), we extracted insights of the different communication channels within GitHub. Using two research questions, we explored the evolution of the channels and adoption of channels by both popular and unpopular library package projects. Results show that (i) contemporary GitHub Projects tend to adopt multiple communication channels, (ii) communication channels change over time and (iii) communication channels are used to both capture new knowledge (i.e., externalization) and updating existing knowledge (i.e., combination). △ Less},
author = {{Authors: Jirateep Tantisuwankul Yusuf Sulistyo Nugroho}, Raula Gaikovina Kula Hideaki Hata Arnon Rungsawang Pattara Leelaprute Kenichi Matsumoto},
journal = {arXiv preprint arXiv:1905.03593},
title = {{A Topological Analysis of Communication Channels for Knowledge Sharing in Contemporary GitHub Projects}},
year = {2019}
}
@inproceedings{10.1145/2597073.2597113,
abstract = { Open-source software projects are primarily driven by community contribution. However, commit access to such projects' software repositories is often strictly controlled. These projects prefer to solicit external participation in the form of patches or pull requests. In this paper, we analyze a set of 89 top-starred GitHub projects and their forks in order to explore the nature and distribution of such community contribution. We first classify commits (and developers) into three categories: core, external and mutant, and study the relative sizes of each of these classes through a ring-based visualization. We observe that projects written in mainstream scripting languages such as JavaScript and Python tend to include more external participation than projects written in upcoming languages such as Scala. We also visualize the geographic spread of these communities via geocoding. Finally, we classify the types of pull requests submitted based on their labels and observe that bug fixes are more likely to be merged into the main projects as compared to feature enhancements. },
address = {New York, NY, USA},
author = {Padhye, Rohan and Mani, Senthil and Sinha, Vibha Singhal},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
doi = {10.1145/2597073.2597113},
isbn = {9781450328630},
keywords = { Open-source software, core committers, external contribution, mining software repositories, pull requests,community participation},
pages = {332--335},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{A Study of External Community Contribution to Open-Source Projects on GitHub}},
url = {https://doi.org/10.1145/2597073.2597113},
year = {2014}
}
@article{10.1007/s10664-019-09709-6,
abstract = {Continuous Integration (CI) is a cornerstone of modern quality assurance, providing on-demand builds (compilation and tests) of code changes or software releases. Yet the many existing CI systems do not help developers in interpreting build results, in particular when facing build inflation. Build inflation arises when each code change has to be built on dozens of combinations (configurations) of runtime environments (REs), operating systems (OSes), and hardware architectures (HAs). A code change C1 sent to the CI system may introduce programming faults that result in all these builds to fail, while a change C2 introducing a new library dependency might only lead one particular build configuration to fail. Consequently, the one build failure due to C2 will be “hidden” among the dozens of build failures due to C1 when the CI system reports the results of the builds. We have named this phenomenon build inflation, because it may bias the interpretation of build results by developers by “hiding” certain types of faults. In this paper, we study build inflation through a large-scale study of the relationship between REs and OSes and build failures on 30 million builds of the CPAN repository on the CPAN Testers package-level CI system. We show that the builds of Perl packages may fail differently on different REs and OSes and any combination thereof . Thus, we show that the results provided by CPAN Testers require filtering and selection to identify real trends of build failures among the many failures. Manual analysis of 791 build failures shows that dependency faults (missing modules) and programming faults (undefined values) are the main reasons for failures, with dependency faults being easier to fix. We conclude with recommendations for practitioners and researchers in interpreting build results as well as for tool builders who should improve he scheduling of builds and the reporting of build failures.},
author = {Gu{\'{e}}h{\'{e}}neuc, Mahdis ZolfaghariniaBram AdamsYann-Ga{\"{e}}l},
doi = {10.1007/s10664-019-09709-6},
journal = {Empirical Software Engineering},
number = {6},
title = {{A study of build inflation in 30 million CPAN builds on 13 Perl versions and 10 operating systems}},
url = {http://link.springer.com/article/10.1007/s10664-019-09709-6},
volume = {24},
year = {2019}
}
@inproceedings{10.1109/ICGSE.2017.1,
abstract = {Establishing trust between developers working at distant sites facilitates team collaboration in distributed software development. While previous research has focused on how to build and spread trust in absence of direct, face-to-face communication, it has overlooked the effects of the propensity to trust, i.e., the trait of personality representing the individual disposition to perceive the others as trustworthy. In this study, we present a preliminary, quantitative analysis on how the propensity to trust affects the success of collaborations in a distributed project, where the success is represented by pull requests whose code changes and contributions are successfully merged into the project's repository.},
author = {Calefato, Fabio and Lanubile, Filippo and Novielli, Nicole},
booktitle = {Proceedings of the 12th International Conference on Global Software Engineering},
doi = {10.1109/ICGSE.2017.1},
isbn = {9781538615874},
keywords = { distributed software development, personality traits, pull requests,trust},
pages = {56--60},
publisher = {IEEE Press},
series = {ICGSE '17},
title = {{A Preliminary Analysis on the Effects of Propensity to Trust in Distributed Software Development}},
url = {https://doi.org/10.1109/ICGSE.2017.1},
year = {2017}
}
@inproceedings{10.1145/3404512.3404520,
abstract = {In this paper, we propose an approach to assess the ability of developers based on their behavior data from OSS. Specifically, we classify developers' ability into code ability, project management ability, and social ability. Code efficiency is related to the developer's commit record and the pull-request record. The developer's project management ability is achieved by tracking the developer's commit record. We use regular matching to map the commit behavior to the project management behavior and calculate the developer's project management ability according to the proportion of different behaviors. The social ability of developers is related to the data that developers interact with in the open-source community. We dug for developer reviews on commit, issue, and gist fragments. By calculating the proportion of positive emotions in developer reviews and the proportion of developers interacting with others in the reviews, the social ability of developers is obtained. We get behavioral data from 50 random developers. Twitter's data is used to test the effect of different machine learning algorithms on the accuracy of developer comment polarity judgments. It is found that the combination of SVM, xgboost and random forest have the highest prediction accuracy. Finally, we select 5 students to use Likert scale to score the results. Our score shows that the results are basically in line with expectations.},
address = {New York, NY, USA},
author = {Zhang, Changqiang and Chen, Ming},
booktitle = {Proceedings of the 2020 2nd International Conference on Big Data Engineering},
doi = {10.1145/3404512.3404520},
isbn = {9781450377225},
keywords = { OSS, developer ability, machine learning,developer ability evaluation},
pages = {82--90},
publisher = {Association for Computing Machinery},
series = {BDE 2020},
title = {{A Multidimensional Approach of Evaluating Developers}},
url = {https://doi.org/10.1145/3404512.3404520},
year = {2020}
}
@inproceedings{8498235,
abstract = {Context: Software code reviews are an important part of the development process, leading to better software quality and reduced overall costs. However, finding appropriate code reviewers is a complex and time-consuming task. Goals: In this paper, we propose a large-scale study to compare performance of two main source code reviewer recommendation algorithms (RevFinder and a Naive Bayes-based approach) in identifying the best code reviewers for opened pull requests. Method: We mined data from Github and Gerrit repositories, building a large dataset of 51 projects, with more than 293K pull requests analyzed, 180K owners and 157K reviewers. Results: Based on the large analysis, we can state that i) no model can be generalized as best for all projects, ii) the usage of a different repository (Gerrit, GitHub) can have impact on the the recommendation results, iii) exploiting sub-projects information available in Gerrit can improve the recommendation results.},
author = {Lipcak, J and Rossi, B},
booktitle = {2018 44th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)},
doi = {10.1109/SEAA.2018.00068},
keywords = { Distributed Software Development, Mining Software Repositories,Bayes methods;data mining;recommender systems;software quality;software reviews;software quality;Naive Bayes-based approach;Gerrit repositories;time-consuming task;source code reviewer recommendation algorithms;software code reviews;complex task;RevFinder complex;data mining;Github repositories;Software;Software algorithms;Data mining;Heuristic algorithms;Prediction algorithms;Measurement;Social network services;Source Code Reviewer Recommendation},
pages = {378--387},
title = {{A Large-Scale Study on Source Code Reviewer Recommendation}},
year = {2018}
}
@inproceedings{10.1145/3127005.3127014,
abstract = {Background: Evidence for the relationship between code review process and software security (and software quality) has the potential to help improve code review automation and tools, as well as provide a better understanding of the economics for improving software security and quality. Prior work in this area has primarily been limited to case studies of a small handful of software projects. Aims: We investigate the effect of modern code review on software security. We extend and generalize prior work that has looked at code review and software quality. Method: We gather a very large dataset from GitHub (3,126 projects in 143 languages, with 489,038 issues and 382,771 pull requests), and use a combination of quantification techniques and multiple regression modeling to study the relationship between code review coverage and participation and software quality and security. Results: We find that code review coverage has a significant effect on software security. We confirm prior results that found a relationship between code review coverage and software defects. Most notably, we find evidence of a negative relationship between code review of pull requests and the number of security bugs reported in a project. Conclusions: Our results suggest that implementing code review policies within the pull request model of development may have a positive effect on the quality and security of software.},
address = {New York, NY, USA},
author = {Thompson, Christopher and Wagner, David},
booktitle = {Proceedings of the 13th International Conference on Predictive Models and Data Analytics in Software Engineering},
doi = {10.1145/3127005.3127014},
isbn = {9781450353052},
keywords = { code review, mining software repositories, multiple regression models, quantification models, software security,software quality},
pages = {83--92},
publisher = {Association for Computing Machinery},
series = {PROMISE},
title = {{A Large-Scale Study of Modern Code Review and Security in Open Source Projects}},
url = {https://doi.org/10.1145/3127005.3127014},
year = {2017}
}
@inproceedings{9045809,
abstract = {With the increasing scale and complexity of software systems, the defects of software are increasing every day. Software defect data is the foundation of research and application of software reliability. Currently, the lack of software defect data, its insufficient coverage, and the limits of the software types involved have become the bottleneck of software reliability research and application. Starting from GitHub, the open-source software hosting platform, this paper analyzes software defect data in open source projects and classifies the available software data. Based on the research of the GitHub and Git repository, we propose a defect data acquisition technology based on open-source software that uses pull requests as the breakthrough point of the method. Moreover, we advanced a software defect data preliminary treatment and built a software defect big datasets collecting system that contains fix-inducing change and contextual information of defects, which solves the class imbalance problem. According to this method, a software defect big data automatic acquisition platform based on GitHub was developed to realize the automatic collection of software defect data. Finally, the efficiency of data collection, correctness of data, and validity of the dataset application were verified by experiments. The results show that the proposed method is efficient and effective.},
author = {Xu, J and Yan, L and Wang, F and Ai, J},
booktitle = {2019 6th International Conference on Dependable Systems and Their Applications (DSA)},
doi = {10.1109/DSA.2019.00020},
keywords = {Big Data;data acquisition;data analysis;pattern classification;program debugging;public domain software;software reliability;software defect data preliminary treatment;software defect big datasets;software defect big data automatic acquisition platform;GitHub-based data collection method;software defect prediction;software systems;software reliability research;open-source software hosting platform;software defect data analysis;Git repository;Contextual Information;Data Collection;Defect Prediction;Fix-inducing Change;Open-Source Software;Software Defects},
pages = {100--108},
title = {{A GitHub-Based Data Collection Method for Software Defect Prediction}},
year = {2020}
}
@article{arXiv:1812.04863,
abstract = {Abstract: Emoji is becoming a ubiquitous language and gaining worldwide popularity in recent years including the field of software engineering (SE). As nonverbal cues, emojis are widely used in user understanding tasks such as sentiment analysis, but few work has been done to study emojis in SE scenarios. This paper presents a large scale empirical study on how GitHub users use emojis in development-related communications. We find that emojis are used by a considerable proportion of GitHub users. In comparison to Internet users, developers show interesting usage characteristics and have their own interpretation of the meanings of emojis. In addition, the usage of emojis reflects a positive and supportive culture of this community. Through a manual annotation task, we find that sentimental usage is a main intention of using emojis in issues, pull requests, and comments, while emojis are mainly used to emphasize important contents in README. These findings not only deepen our understanding about the culture of SE communities, but also provide implications on how to facilitate SE tasks with emojis such as sentiment analysis. △ Less},
author = {{Authors: Xuan Lu Yanbin Cao}, Zhenpeng Chen Xuanzhe Liu},
journal = {arXiv preprint arXiv:1812.04863},
title = {{A First Look at Emoji Usage on GitHub: An Empirical Study}},
year = {2018}
}
@inproceedings{Yu2018,
abstract = {In GitHub, the pull-based development model enables community contributors to collaborate in a more efficient way. However, the distributed and parallel characteristics of this model pose a potential risk for developers to submit duplicate pull-requests (PRs), which increase the extra cost of project maintenance. To facilitate the further studies to better understand and solve the issues introduced by duplicate PRs, we construct a large dataset of historical duplicate PRs extracted from 26 popular open source projects in GitHub by using a semi-automatic approach. Furthermore, we present some preliminary applications to illustrate how further researches can be conducted based on this dataset.},
author = {Yu, Y and Li, Z and Yin, G and Wang, T and Wang, H},
booktitle = {2018 IEEE/ACM 15th International Conference on Mining Software Repositories (MSR)},
isbn = {2574-3864 VO -},
keywords = {Computational modeling,Data mining,Databases,Duplicate pull-request,GitHub,Maintenance engineering,Manuals,Software,Tools,Web services,community contributors,data handling,dataset,distributed software development,duplicate pull-requests,historical duplicate PR,open source projects,project maintenance,pull-based development model},
pages = {22--25},
title = {{A Dataset of Duplicate Pull-Requests in GitHub}},
year = {2018}
}
@inproceedings{10.1145/2597073.2597122,
abstract = { Pull requests form a new method for collaborating in distributed software development. To study the pull request distributed development model, we constructed a dataset of almost 900 projects and 350,000 pull requests, including some of the largest users of pull requests on Github. In this paper, we describe how the project selection was done, we analyze the selected features and present a machine learning tool set for the R statistics environment. },
address = {New York, NY, USA},
author = {Gousios, Georgios and Zaidman, Andy},
booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
doi = {10.1145/2597073.2597122},
isbn = {9781450328630},
keywords = { distributed software development, empirical software engineering, pull request,pull-based development},
pages = {368--371},
publisher = {Association for Computing Machinery},
series = {MSR 2014},
title = {{A Dataset for Pull-Based Development Research}},
url = {https://doi.org/10.1145/2597073.2597122},
year = {2014}
}
@article{arXiv:2001.07808,
abstract = {Abstract: Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application's code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that the build tool packages with the application's compiled code but that are actually not necessary to build and run the application. This phenomenon artificially grows the size of the built binary and increases maintenance effort. We propose a tool, called DepClean, to analyze the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is that 75.1{\%} of the analyzed dependency relationships are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts up to 1/4 of its current count. We also perform a qualitative study with 30 notable open-source projects. Our results indicate that developers pay attention to their dependencies and are willing to remove bloated dependencies: 18/21 answered pull requests were accepted and merged by developers, removing 131 dependencies in total. △ Less},
author = {{Authors: C{\'{e}}sar Soto-Valero Nicolas Harrand}, Martin Monperrus Benoit Baudry},
journal = {arXiv preprint arXiv:2001.07808},
title = {{A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem}},
year = {2020}
}
@inproceedings{Liu2016,
abstract = {There is a trend in increased social involvement in software development process. Facilities supporting distributed software development and management have become a common practice in the community. Public involvement is further promoted by the incorporation of the social network features brought about by GitHub. The “following”and “watching”mechanisms, together with the pull-request facility, encourage wider and deeper involvement of the general public. While earlier studies have begun to study the possible effects of the increased publicity, their approaches are based on qualitative methods and their conclusions are only tentative. In this paper, we conduct a comparative study on the effects of pull request on 461 GitHub projects. Correlation study, factor analysis and MannWhitneyWilcoxon Test are conducted on the bug report data we gather from GitHub. From the empirical observations, we found that employing pull request can help increase the social impact of projects, resulting in more active development activity. However, it could also lead to prolonged bug fixing time.},
author = {Liu, J and Li, J and He, L},
booktitle = {2016 IEEE 40th Annual Computer Software and Applications Conference (COMPSAC)},
doi = {10.1109/COMPSAC.2016.27},
isbn = {0730-3157 VO - 1},
keywords = {Computer bugs,GitHub,GitHub project,Mann-Whitney-Wilcoxon test,Market research,Open source software,Social network services,Software engineering,Testing,active development activity,bug fixing,bug fixing time,bug report data,configuration management,correlation study,distributed software development,distributed version control system,factor analysis,following mechanism,program debugging,project management,pull request,pull-request facility,social impact,social involvement,social network,social networking (online),software development management,software development process,watching mechanism},
pages = {313--322},
title = {{A Comparative Study of the Effects of Pull Request on GitHub Projects}},
volume = {1},
year = {2016}
}
@inproceedings{7816585,
abstract = {The incorporation of peer code reviews as being part of a developer's work flow, and hence the software development lifecycle, has steadily grown in popularity over the past three decades. During the process of statically inspecting code, developers of a codebase are able to collaboratively detect possible code defects, as well as use code reviews as a means of transferring knowledge to improve the overall understanding of a system. The uptake of such practices is dependent on several factors, specifically the availability of tools that aid in providing an easy-to-use and intuitive platform to perform code reviews, and is readily accessible to members of a project. This paper briefly explores the act of code review, identifies the pitfalls of existing code review tools, and proposes the design and development of a web-based code review application, along with the evaluation of the prototype. The code review tool developed, Fistbump, targets the popular Git based repository hosting service, GitHub, and provides a versatile tool to coordinate and manage discussions between the owner of a pull request and the elected participants of a review.},
author = {Kalyan, A and Chiam, M and Sun, J and Manoharan, S},
booktitle = {2016 21st International Conference on Engineering of Complex Computer Systems (ICECCS)},
doi = {10.1109/ICECCS.2016.032},
keywords = {groupware;Internet;program debugging;software development management;software tools;source code (software);code defect detection;Git based repository hosting service;Fistbump;Web-based code review application;code review tools;software development lifecycle;GitHub;collaborative code review platform;Software;Inspection;Industries;Collaboration;Servers;Message systems;Computers;Code Review;Team Programming;Collaborative Platform},
pages = {191--196},
title = {{A Collaborative Code Review Platform for GitHub}},
year = {2016}
}

38
experiment/study-search/papers-5.bib Normal file
View File

@ -0,0 +1,38 @@
@inproceedings{10.1109/ICSE.2019.00123,
abstract = {Links are an essential feature of the World Wide Web, and source code repositories are no exception. However, despite their many undisputed benefits, links can suffer from decay, insufficient versioning, and lack of bidirectional traceability. In this paper, we investigate the role of links contained in source code comments from these perspectives. We conducted a large-scale study of around 9.6 million links to establish their prevalence, and we used a mixed-methods approach to identify the links' targets, purposes, decay, and evolutionary aspects. We found that links are prevalent in source code repositories, that licenses, software homepages, and specifications are common types of link targets, and that links are often included to provide metadata or attribution. Links are rarely updated, but many link targets evolve. Almost 10{\%} of the links included in source code comments are dead. We then submitted a batch of link-fixing pull requests to open source software repositories, resulting in most of our fixes being merged successfully. Our findings indicate that links in source code comments can indeed be fragile, and our work opens up avenues for future work to address these problems.},
author = {Hata, Hideaki and Treude, Christoph and Kula, Raula Gaikovina and Ishio, Takashi},
booktitle = {Proceedings of the 41st International Conference on Software Engineering},
doi = {10.1109/ICSE.2019.00123},
pages = {1211--1221},
publisher = {IEEE Press},
series = {ICSE '19},
title = {{9.6 Million Links in Source Code Comments: Purpose, Evolution, and Decay}},
url = {https://doi.org/10.1109/ICSE.2019.00123},
year = {2019}
}
@inproceedings{DBLP:conf/icc/YuXZWLL18,
author = {Yu, Song and Xu, Li and Zhang, Yan and Wu, Jinsong and Liao, Zhifang and Li, Yanbing},
booktitle = {2018 {\{}IEEE{\}} International Conference on Communications, {\{}ICC{\}} 2018, Kansas City, MO, USA, May 20-24, 2018},
doi = {10.1109/ICC.2018.8422103},
pages = {1--6},
publisher = {IEEE},
title = {{{\{}NBSL:{\}} {\{}A{\}} Supervised Classification Model of Pull Request in Github}},
url = {https://doi.org/10.1109/ICC.2018.8422103},
year = {2018}
}
@inproceedings{8453184,
abstract = {Testing is an integral part of the software development lifecycle, approached with varying degrees of rigor by different process models. Agile process models recommend Test Driven Development (TDD) as a key practice for reducing costs and improving code quality. The objective of this work is to perform a cost-benefit analysis of this practice. Previous work by Fucci et al. [2, 3] engaged in laboratory studies of developers actively engaged in test-driven development practices. Fucci et al. found little difference between test-first behaviour of TDD and test-later behaviour. To that end, we opted to conduct a study about TDD behaviours in the "wild" rather than in the laboratory. Thus we have conducted a comparative analysis of GitHub repositories that adopts TDD to a lesser or greater extent, in order to determine how TDD affects software development productivity and software quality. We classified GitHub repositories archived in 2015 in terms of how rigorously they practiced TDD, thus creating a TDD spectrum. We then matched and compared various subsets of these repositories on this TDD spectrum with control sets of equal size. The control sets were samples from all GitHub repositories that matched certain characteristics, and that contained at least one test file. We compared how the TDD sets differed from the control sets on the following characteristics: number of test files, average commit velocity, number of bug-referencing commits, number of issues recorded, usage of continuous integration, number of pull requests, and distribution of commits per author. We found that Java TDD projects were relatively rare. In addition, there were very few significant differences in any of the metrics we used to compare TDD-like and non-TDD projects; therefore, our results do not reveal any observable benefits from using TDD.},
address = {New York, NY, USA},
author = {Borle, Neil C and Feghhi, Meysam and Stroulia, Eleni and Grenier, R and Hindle, Abram and Greiner, Russell and Hindle, Abram},
booktitle = {Proceedings of the 40th International Conference on Software Engineering},
doi = {10.1145/3180155.3182535},
isbn = {9781450356381},
issn = {1558-1225},
keywords = {,Analytical models,Blogs,Computational modeling,Continuous Integration,GitHub Repositories,GitHub repositories,Human Factors in Software Development,Java,Java TDD projects,Software,Software engineering,TDD sets,TDD spectrum,Test Driven Development,Testing,agile process models,continuous integration,control sets,cost-benefit analysis,human factors in software development,improving code quality,nonTDD projects,program testing,software development lifecycle,software development productivity,software engineering,software maintenance,software quality,software reliability,test driven development,test file,test-driven development practices,test-first behaviour,test-later behaviour},
pages = {1062},
publisher = {Association for Computing Machinery},
series = {ICSE '18},
title = {{[Journal First] Analyzing the Effects of Test Driven Development in GitHub}},
url = {https://doi.org/10.1145/3180155.3182535},
year = {2018}
}

0
study-search/springer.bib → experiment/study-search/springer.bib
View File

0
study-search/springer.csv → experiment/study-search/springer.csv
View File

BIN
main.pdf Normal file
View File

Binary file not shown.

115
main.tex Normal file
View File

@ -0,0 +1,115 @@
\documentclass[10pt,journal,compsoc]{IEEEtran}
% *** CITATION PACKAGES ***
%
\ifCLASSOPTIONcompsoc
% IEEE Computer Society needs nocompress option
% requires cite.sty v4.0 or later (November 2003)
\usepackage[nocompress]{cite}
\else
% normal IEEE
\usepackage{cite}
\fi
\usepackage{colortbl}
\usepackage{arydshln}
\usepackage{breakurl}
\usepackage{framed}
\usepackage{tcolorbox}
\usepackage{graphicx}
\usepackage{subfig}
\usepackage{color,soul}
\usepackage{colortbl}
\usepackage{xcolor}
\usepackage{enumerate}
\usepackage{enumitem}
\usepackage{multirow,booktabs}
\usepackage{caption}
\usepackage{dcolumn}
\usepackage{xspace}
\usepackage{balance}
\usepackage{bm}
\usepackage{cite}
\usepackage[hyphens]{url}
\usepackage{hhline}
\usepackage{setspace}
\usepackage{bbding}
\usepackage{tabularx}
\usepackage{arydshln}
\newcommand{\ie}{{\textit{i.e.}},\xspace}
\newcommand{\eg}{{\textit{e.g.}},\xspace}
\newcommand{\etc}{\textit{etc.}\xspace}
\newcommand{\etal}{{\textit{et al.}}}
% correct bad hyphenation here
\hyphenation{}
\begin{document}
\title{What Have Been Studied on GitHub Pull Request?: A Systematic Review}
\author{
****
}
\IEEEtitleabstractindextext{%
\begin{abstract}
****
\end{abstract}
% Note that keywords are not normally used for peerreview papers.
\begin{IEEEkeywords}
***
\end{IEEEkeywords}
}
% make the title area
\maketitle
\IEEEdisplaynontitleabstractindextext
\IEEEpeerreviewmaketitle
\ifCLASSOPTIONcompsoc
\section*{Acknowledgments}
\else
% regular IEEE prefers the singular form
\section*{Acknowledgment}
\fi
This work was supported by National Grand R\&D Plan (Grant No. 2018AAA0102304) and National Natural Science Foundation of China (Grant No. 61702534).
\ifCLASSOPTIONcaptionsoff
\newpage
\fi
\input{1-introduction.tex}
\input{2-slr-procedure.tex}
\bibliographystyle{plain}
\bibliography{ref}
\end{document}

BIN
paper collection.pptx
View File

Binary file not shown.

8
ref.bib Normal file
View File

@ -0,0 +1,8 @@
@inproceedings{Gousios:2014,
title={An exploratory study of the pull-based software development model},
author={Gousios, Georgios and Pinzger, Martin and Deursen, Arie Van},
booktitle={Proceedings of the 36th International Conference on Software Engineering},
pages={345-355},
year={2014},
organization={ACM}
}