60 lines
3.3 KiB
TeX
60 lines
3.3 KiB
TeX
\section{RELATED WORK}
|
||
\label{sec:RelatedW}
|
||
|
||
\subsection{Code Review}
|
||
Code review is employed by many software projects to
|
||
examine the change made by others in source codes,
|
||
find potential defects,
|
||
and ensure software quality before they are merged~\cite{Baysal:2015,Mcintosh:***}.
|
||
Traditional code review,
|
||
which is also well known as the code inspection proposed by Fagan~\cite{Fagan:1976},
|
||
has been performed since the 1970s.
|
||
However, its cumbersome and synchronous characteristics have hampered
|
||
its universal application in practice~\cite{Bacchelli:2013}.
|
||
With the occurrence and development of VCS and collaboration tools,
|
||
Modern Code Review (MCR)~\cite{Rigby:2011} is adopted by many software companies and teams.
|
||
Different from formal code inspections,
|
||
MCR is a lightweight mechanism that is less time consuming and supported by various tools.
|
||
While the main motivation for code review was believed
|
||
to be finding defects to control software quality,
|
||
recent research has revealed that defect elimination is not the sole motivation.
|
||
Bacchelli \etal~\cite{Bacchelli:2013} reported additional expectations,
|
||
including knowledge transfer, increased team awareness,
|
||
and creation of alternative solutions to problems.
|
||
|
||
\subsection{Pull-request}
|
||
Although research on pull requests is in its early stages,
|
||
several relevant studies have been conducted.
|
||
Gousios \etal~\cite{Gousios:2014,Rigby:2014} conducted a statistical analysis
|
||
of millions of pull requests from GitHub and analyzed the popularity of pull requests,
|
||
the factors affecting the decision to merge or reject a pull request,
|
||
and the time to merge a pull request.
|
||
Tsay \etal~\cite{Tsay:2014b} examined how social
|
||
and technical information are used to evaluate pull requests.
|
||
Yu \etal~\cite{Yu:2016} conducted a quantitative study on pull request evaluation in the context of CI.
|
||
Moreover, Yue \etal~\cite{Yu:2015} proposed an approach that combines information retrieval
|
||
and social network analysis to recommend potential reviewers.
|
||
Veen \etal~\cite{Veen:2015} presented PRioritizer,
|
||
a prototype pull-request prioritization tool,
|
||
which works to recommend the top pull requests the project owner should focus on.
|
||
|
||
|
||
% !!!!!!!!!!!!!!Collaboratively Generated Data说法？？？
|
||
\subsection{Classification on Collaboratively Generated Data}
|
||
Several studies have been performed to analyze free text
|
||
generated in the software development process.
|
||
Antoniol \etal~\cite{Antoniol:2008} conducted a survey on 1,800 issues
|
||
from the BTS of three large open-source systems
|
||
and concluded that the linguistic information contained in these issues
|
||
is sufficient to distinguish ``bug'' issues from ``non-bug'' ones.
|
||
Later on, Pingclasai \etal~\cite{Pingclasai:2013} used topic modeling
|
||
to classify bug reports.
|
||
Herzig \etal~\cite{Herzig:2013} conducted a fine-grained classification on 7,000 issue reports
|
||
and analyzed the classification results of early research.
|
||
Zhou \etal~\cite{Zhou:2014} proposed a hybrid approach
|
||
by combining text-mining and data-mining techniques
|
||
to automatically classify bug reports.
|
||
Ciurumelea \etal~\cite{Ciurumelea:2017} studied reviews on mobile apps,
|
||
proposed an approach to automatically organize reviews according
|
||
to predefined tasks (battery, performance, memory, privacy, etc.),
|
||
and recommended the related source code that should be modified. |